Enable module default streams in the buildroot repository for modular and non-modular RPMs.
I still haven't heard back about https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JX7CNMIYVWBY4PWV3QQIDQGOTSNQJB5D/
Anyway, given the above, and this:
https://pagure.io/fesco/issue/2003#comment-607196
And this:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/JJ67QWPFS6T3MFPTCFEJ6RWAVWLI5ZJZ/ and that entire thread basically and also the other 2 threads.
I must vote -1. Allowing nonmodular packages to buildrequire modular packages in any form in the current state of our tools, design a packages, is a dangerous path. Enabling this would be a disservice to our community.
I agree with Miro, -1 as well.
-1
Metadata Update from @ignatenkobrain: - Issue tagged with: meeting
+1 - while there are certainly some issues with module default streams that still need to be ironed out, default module streams are something that we already have in Fedora, and the equivalence "default module stream <=> ursine buildroot" seems both necessary and natural.
I don't think there were any issues in devel thread that weren't answered. It might be good if some of the answers got fed back into the change proposal.
Here are my top reasons to vote -1:
Ursa Major was rejected earlier by FESCo, and Ursa Prime (the heart of this proposal) was conceived and coordinated with numerous other people to have a more agreeable solution for Fedora. To now turn that down as well seems like moving the goal posts unfairly.
On a more philosophical note, it's OK for there still to be some issues to iron out in a relatively new technology. This is an iterable concept for which Fedora is designed and intended.
To now turn that down as well seems like moving the goal posts unfairly.
It was discussed via https://pagure.io/fesco/issue/2003 and never agreed upon.
Either way accepting such a big change on the idea that it would be unfair not to do so would be... well, unfair to our users and our community.
As requested, I've put together a document (with help from @churchyard) describing what would be required to drop default streams in Fedora 32.
I've also sent FESCo members a link directly to allow them to comment on the document directly. The link in this comment is public and can be viewed by anyone. (It should auto-update with any edits we make.)
Ugh, that link doesn't work outside Red Hat... let me see what I can do about that. Please hold.
Let's try attaching an exported PDF.
<img alt="Default_Stream_Exodus.pdf" src="/fesco/issue/raw/files/3f98bbf85ff9ef16b1f1614c1de931b0c8a3999210308a5c353dbb2a8bad22ff-Default_Stream_Exodus.pdf" />
Is there any idea from dnf maintainers (who I assume would have to work to make any of those things happen on upgrades) how long they might take? ie, longer than until f32beta?
I'm commenting the idea of dropping the defaults:
If you decide to drop the defaults from the distro, they will simple stop working, no dnf change is needed.
My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly. Users will have to enable streams by hand if they want to install some packages. That's currently not possible using Gnome Software, they'll have to use DNF. It also looks that the stream upgrades will become a problem of the end users. I'd expect that all streams we ship in Fedora N have clear transition to Fedora N+1.
There should be a concept of stream life cycles including dropping a stream or obsoleting a stream with another. Everything else is merely a workaround.
I'm commenting the idea of dropping the defaults: If you decide to drop the defaults from the distro, they will simple stop working, no dnf change is needed. My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly. Users will have to enable streams by hand if they want to install some packages. That's currently not possible using Gnome Software, they'll have to use DNF. It also looks that the stream upgrades will become a problem of the end users. I'd expect that all streams we ship in Fedora N have clear transition to Fedora N+1. There should be a concept of stream life cycles including dropping a stream or obsoleting a stream with another. Everything else is merely a workaround.
@dmach I don't disagree with anything you've said, but the concern FESCo has is that because the lifecycle stuff hasn't been sorted out yet, we should temporarily stop using default streams in Fedora. We can ask to restore them later once we have figured out the upgrade/obsolete problems. So we're looking to see what it would take to back the default streams out for now.
My personal opinion is that by dropping the defaults you'll make Fedora user unfriendly. Users will have to enable streams by hand if they want to install some packages.
Not if the defaults are in non-modular Fedora, which is what I have always advocated for.
Metadata Update from @jforbes: - Issue untagged with: meeting
AGREED: Ursa Prime in rawhide with the remark that it doesn't expose everything, not even "default everything" but rather exposes only vetted list of modules (+5,0,-3) (jforbes, 16:21:28) AGREED: For the purposes of testing, we will allow the avocado and dwm modules in the Ursa Prime buildroot (+5,0,-3) (jforbes, 16:30:38)
See https://pagure.io/releng/fedora-module-defaults/pull-request/184
I added overrides for the ant, gimp, maven and scala modules to drop their default stream from the buildroot.
AGREED: Ursa Prime in rawhide with the remark that it doesn't expose everything, not even "default everything" but rather exposes only vetted list of modules (+5,0,-3) (jforbes, 16:21:28) AGREED: For the purposes of testing, we will allow the avocado and dwm modules in the Ursa Prime buildroot (+5,0,-3) (jforbes, 16:30:38) For my understanding, should this be interpreted as "change accepted" or "decision deferred until we see the results of this test"?
For my understanding, should this be interpreted as "change accepted" or "decision deferred until we see the results of this test"?
This effectively means "change accepted". Only two modules are authorized, but if more are to be authorized, it would be better to open a new ticket. Let's close this.
Metadata Update from @zbyszek: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
Log in to comment on this ticket.