This is a revival of a proposal that was raised in [0]. Some votes were cast, but then in the meeting we decided to wait until the Council meeting with the dnf/modularity team on 10/06/2020. The number of comments in #2114 is such that it's hard to find stuff, so I'm re-proposing here.
*modular*.repo
[edited to change point 1. based on the discussion later in the ticket.]
Clarification a: let's assume that this proposal is separate from the previous one. I made some wording changes and changed the order, and we shouldn't carry over votes. Nevertheless, to simplify discussion, I'm including all four original points, even if I do not agree with all of them.
Clarification b: point 2. only covers Fedora proper, i.e. rawhide and any of the releases. Default modules in ELN are discussed in #2390 and are a separate issue.
My vote: +1, +1, +1, +1, -1
Discussion (my view, not part of the proposal text):
Module-only packages have a viral effect whereby dependent packages must depend on the modular version of the rpm. Requiring a non-modular version of the package obviously solves this issue, but in addition has other benefits: version conflicts are clearly visible, rpms are available to users who do not want to use modules, and there is clear ownership of the default version of rpms. Since modules are composed of rpms, and to build a module the rpms must be developed anyway, it is fine to require those rpms to be built and made available in the usual fashion.
Default streams aren't necessary when 1. is true. Default streams would make modules mandatory for all users. Switching of the default stream breaks dependent packages. See [1, 2, 3] for detailed arguments.
Compat packages are much nicer for users: they are easier to discover, any versions conflicts are clearly reported by dnf, and parallel installability is possible [4].
This is implemented by [5]. As discussed in the pull request, this split allows users who wish to opt out of modules to do so, without changing the experience for users who use modules.
Disabling modular repos on new installations makes it a tiny bit more complicated to enable modules (an extra dnf command would be required). To make things as simple as possible for users, I think we should keep current state of having modular repos enabled, and I'm voting against this item.
[0] https://pagure.io/fesco/issue/2114#comment-653212 [1] https://pagure.io/fesco/issue/2114#comment-655063 [2] https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122310 [3] https://pagure.io/fedora-docs/modularity/pull-request/83#comment-122579 [4] https://pagure.io/fesco/issue/2114#comment-655020 [5] https://src.fedoraproject.org/rpms/fedora-repos/pull-request/62
To answer comments raised in the previous iterations: the changes proposed here (with the possible exception of point 5.), do not impact users of modules compared to status quo. They also do not prevent development of Modularity or of individual modules.
The reasons were already presented numerous times elsewhere.
I don't want to kill modularity entirely, I think it's beneficial to have it enabled by default, so users can consume alternate content from it in an easy way.
Side note: I've already proposed 4) as a Fedora change: https://fedoraproject.org/wiki/Changes/ModularReposSubpackage -- happy to withdraw the proposal if we agree on this here.
ban module-only packages: modular versions should only be allowed as alternatives to existing packages.
+1
make the ban on default streams in Fedora permanent (as they are now provisionally).
encourage compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability).
make modular.repo optional by splitting them into a separate package.
disable modular.repo by default in new installations.
+1 because I don't want a repeat of the Java disaster
+1 with noting that permanence in this case is only if the technology does not change in such a way that makes it more sustainable to manage default streams (though I do agree that if we mandate non-modular variants, this is superfluous)
+1 with the caveat that if the packaging for stuff like Python modules, Ruby Gems, etc. can be made to handle parallel installability as the interpreters do by default. Whether alternate language stack builds are done using modularity tooling or not, I'd like for us to avoid install conflicts if we can.
+1 because this makes sense to me to give people flexibility here
-1 because I think with the previous point, this is superfluous. I'd rather have those files enabled by default if I install the package providing the modular content repositories.
noting that permanence in this case is only if the technology does not change in such a way that makes it more sustainable to manage default streams
Technically, any decision can change over time. I'd rather avoid saying such things explicitly in the approved statement to avoid false expectations (such as the narrative that this ban is temporary)
noting that permanence in this case is only if the technology does not change in such a way that makes it more sustainable to manage default streams Technically, any decision can change over time. I'd rather avoid saying such things explicitly in the approved statement to avoid false expectations (such as the narrative that this ban is temporary)
The main reason I say this is that I don't want to discourage development of a solution that makes it so that we would consider revisiting this decision. Unequivocal bans are not encouraging...
I don't want this discussion to be blocked on this. Hence I can accept such note.
with noting that permanence in this case is only if the technology does not change in such a way that makes it more sustainable to manage default streams I don't want this discussion to be blocked on this. Hence I can accept such note.
with noting that permanence in this case is only if the technology does not change in such a way that makes it more sustainable to manage default streams
Same here. I don't think this rider changes much, but OK.
with the caveat that if the packaging for stuff like Python modules, Ruby Gems, etc. can be made to handle parallel installability as the interpreters do by default.
Let's please handle this as a separate issue. If you want to, please make a proposal. Parallel installability is complicated and requires additional packaging effort.
If we want to encourage parallel-installable packages, we need to have people proposing how they intend to support it. It is only separate in that a defined policy isn't going to be set right now (that's up to the SIGs to handle), but I am saying that this is explicitly something that needs to be resolved over time in order for that part of the proposal to work in practice.
make the temporary ban on default streams in Fedora "permanent"
does this mean
a) not installing the subpackage containing the modular repos by default, b) setting enabled=0 in the *modular*.repo files, or c) both of the above?
enabled=0
I think c) doesn't make sense, but I would vote +1 for a) and b), however I think a) would be a cleaner solution, and a simpler "upgrade path" for users who want to consume modules.
I understand "disable modular.repo by default in new installations" as not installing the separate package by default. When the package is installed, the repos are enabled (having to install the package + edit the config is very redundant). Hence a). However in the unlikely event of us approving 5 but not 4, it would need to be b).
I understand "disable modular.repo by default in new installations" as not installing the separate package by default. When the package is installed, the repos are enabled (having to install the package + edit the config is very redundant).
Exactly.
-1 Even if we don't enable default streams, module-only packages may still have value if they need to depend on a version of a dependency that is otherwise incompatible with the non-modular set. This should be discouraged and the package should be aided in migrating to the system version of the dependency, but it should still be permitted in cases where it's difficult/impossible/too time-consuming to make it work.
-1 This is premature. Please let us have them in ELN and we can figure out if they can be made to work in an acceptable manner.
+1 We already do this (and it's part of my WIP policy draft in https://pagure.io/fedora-docs/modularity/pull-request/83)
0 I don't think this makes much difference one way or the other.
-1 One of the cited problems you've claimed repeatedly is discoverability. This has been improved (and continues to improve), but disabling the modular repo by default would serve only to make that problem worse. Doing this serves no purpose other than to throw up yet another roadblock to adoption.
I have other comments on the rest of the discussion section, but I have a meeting to get to right now.
Even if we don't enable default streams, module-only packages may still have value if they need to depend on a version of a dependency that is otherwise incompatible with the non-modular set. This should be discouraged and the package should be aided in migrating to the system version of the dependency, but it should still be permitted in cases where it's difficult/impossible/too time-consuming to make it work.
I was thinking about this case. I'd suggest we could say something like:
"Modular only packages are not allowed. There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such exceptions can be granted by FESCo."
For the time being, such exceptions are approved at FESCo
I would prefer if we change this to the "For the time being, such exceptions can be granted by FESCo". Or probably this should be deferred to the FPC same as bootstrap exceptions and such.
But generally I am not opposed to this.
Metadata Update from @churchyard: - Issue tagged with: meeting
I would prefer if we change this to the "For the time being, such exceptions can be granted by FESCo".
I've edited the text.
Yeah. Requiring FESCo approval seems reasonable. I don't expect this to be a particularly common case.
Is anyone opposed to editing the original proposal to include this text?
Fine by me.
I edited the text as agreed now.
-1
I would also like to see something around changing the Fedora Packager guidelines with regards to maintaining modules and what is expected. I am happy to work with others on drafting those changes. For me, the expectation is that any package that already exists as a package should continue to. It can become part of a module, but the existing non-module package needs to remain.
The proposal above looks reasonable to make modules available but not unexpectedly invasive on a system.
* AGREED: Modular-only packages are not allowed and modular versions are only be allowed as alternatives to non-modular packages. (+9, 0, -0) (contyk, 15:58:47) * There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. As an example if non-modular Fedora has dnf 4, and there is module with dnf 5, a package that only works with dnf 5 can remain modular only, until dnf 5 is included in non-modular Fedora. For the time being, such (contyk, 15:58:54) * AGREED: Default streams are not allowed in Fedora. This may be revised in the future, especially if the functionality of default streams is improved. (+9, 0, -0) (contyk, 16:00:26) * AGREED: Encourage compatibility packages rather than modules wherever reasonable (e.g., libraries, language interpreters, …, and anything that can benefit from parallel installability). (+9, 0, -0) (contyk, 16:02:07) * AGREED: Make *modular*.repo optional by splitting them into a separate package. (+8, 1, -0) (contyk, 16:03:24) * AGREED: Disable *modular*.repo by default in new installations. (2, 0, -7) (contyk, 16:04:58) * Modular repo will remain enabled. (contyk, 16:05:05)
Metadata Update from @ignatenkobrain: - Issue untagged with: meeting
Metadata Update from @ignatenkobrain: - Issue close_status updated to: Accepted - Issue status updated to: Closed (was: Open)
There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only.
Sigh… This is a loophole big enough to drive an elephant through. :-(
There is an exception to this rule: if the package does not function in non-modular Fedora (with reasonable amount of work), it is permitted to have it in module only. Sigh… This is a loophole big enough to drive an elephant through. :-(
This exception was driven by @sgallagh, and I consider it a reasonable one. I think he'll do some reasonable effort to clarify what this means so that it's clear where this is okay.
The elephant loophole still requires an explicit FESCo approved exception.
* AGREED: Disable *modular*.repo by default in new installations. (2, 0, -7) (contyk, 16:04:58) * Modular repo will remain enabled. (contyk, 16:05:05)
It seems that the packaging change has been made in a way which doesn't respect these decisions. Since fedora-repos-33-0.8 landed in Rawhide yesterday, the modular repos are in a fedora-repos-modular subpackage, and that subpackage is not installed out of the box, at least not on a default Server DVD install. I had to adjust the openQA module test to install it before running, or else it failed because no modules were available.
fedora-repos-modular
At first I thought this change was intentional and desired from the discussion in #2114, but it seems not.
@adamwill The package is installed by default if you upgrade. It is not installed by default for new installs.
but...that's the opposite of what the above minutes suggest was expected. The vote was to install it (and hence enable the repos) in new installations. Here is the full log of the relevant vote:
16:03:36 <contyk> Proposal: Disable *modular*.repo by default in new installations. 16:03:40 <mhroncok> -1 16:03:41 <King_InuYasha> -1 16:03:45 <nirik> -1 16:03:46 <dcantrell> -1 16:04:02 <decathorpe> +1 16:04:03 <sgallagh> -1 16:04:09 <cverna> -1 16:04:10 <ignatenkobrain> +1 16:04:32 <zbyszek> -1 16:04:34 <contyk> zbyszek: ? 16:04:58 <contyk> #agreed Disable *modular*.repo by default in new installations. (2, 0, -7) 16:05:05 <contyk> #info Modular repo will remain enabled.
That reads to me like FESCo clearly expects the repos to be present and enabled in fresh installs, still.
The way I recall it, it was being asked to disable the repos along with splitting out the repos into a package. I considered that unnecessary, given that it was split out into a package and the package can be trivially installed or uninstalled to have access to the content.
@adamwill yes, it was our intent that the -modular repos package should stay installed during upgrades and get installed on fresh installs (even if I voted against that).
it looks like the "make sure this can be removed" action also triggered "this isn't getting pulled in by anything anymore, which is a "bug". does the modular repo package need to be added to some comps group or kickstart config for this to work as expected? I assume so.
I'm not sure offhand what would be the best way to do it. Presumably it should be as similar as possible to how we pull in fedora-repos, however we do that.
I believe fedora-release requires fedora-repos and vice versa?
fedora-release
fedora-repos
And hence doing it the same way for fedora-repos-modular is not doable, as it would defeat the point of the subpackage.
And what FESCo voted was that the .repo file should remain enabled, as in, have enabled=1 set. That does not imply that it has to actually be installed.
.repo
enabled=1
There's: https://pagure.io/fedora-comps/pull-request/510 (a pr to add it to @core), but that seems wrong to me... I think adding it to fedora-release-common is best. That would also handle autoremove removing it.
Adding it to fedora-release-common effectively prevents removing it, so that is not acceptable. (Even if you make it a soft dependency, see https://bugzilla.redhat.com/show_bug.cgi?id=1699672 .)
fedora-release-common
The reason it wasn't made a Recommends: dep is that anything Recommend'ed ends up getting pulled back in on any transaction that touches any package that does the Recommend'ing. (Long-standing libsolv issue that was closed as "it's a feature, not a bug": https://github.com/openSUSE/libsolv/issues/168 )
Recommends:
Recommend
libsolv
Maybe it's not a problem if fedora-release-common is never updated in the lifetime of a Major Fedora Release.
Ah yeah, you're right. I guess adding it to core is the thing to do then. ;(
Yes, we should put it to the comps. Moreover, we should do it for fedora-repos too.
It seems that the packaging change has been made in a way which doesn't respect these decisions.
It was an unfortunate timing of two related changes, see
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/WALAC2ESZCSG264IPZWR2Y2OSSNA7DYH/
FTR the details are handled via https://fedoraproject.org/wiki/Changes/ModularReposSubpackage and the tracking bug is https://bugzilla.redhat.com/show_bug.cgi?id=1852028 -- feel free to report further problems there.
@kkofler I agree you could technically read the text of the proposal that way, but my reading from the whole meeting log is that FESCo folks thought they were voting on "repos should be enabled out of the box in Fedora installs", not "repos should be enabled in the package but the package should not be installed". If any FESCo members thought they were voting for "repos should be enabled in the package but the package should not be installed by default", please say so :)
FTR, @adamwill's interpretation is how I view it. It's supposed to be trivially removable, not removed.
Login to comment on this ticket.