On Tue, Jun 23, 2020 at 5:14 AM Zbigniew Jędrzejewski-Szmek
On Mon, Jun 22, 2020 at 03:36:30PM -0400, Josh Boyer wrote:
> We know within RHEL we have teams that will likely continue using
> default streams. We also know that some teams will not. Further we
> know that somes teams will likely not use modules at all, just as
> teams in RHEL 8 did not use modules. The flexibility to choose the
> approach that makes the most sense for that team and their package set
> would be what I would hope we try to enable in Fedora and ELN. It is
> fair to ask why a team would want to continue using default streams,
> and I can offer guesses but they would be only that. I would hope
> such teams could freely chime in here. The point is, within RHEL it
> is actually their choice to make, balancing the needs of their
> customers with the content they are packaging, etc.
[After clearing up my misunderstanding about terminology in the other subthread:]
The choice of allowing "default module streams" is not a choice that
should be taken lightly on the level of individual contributors /
teams, because it impacts the way other teams build *their* packages
and/or modules. In particular, if "enabled", other maintainers need
to remain aware of modules and need to take the quirks of modularity
into account when working on their packages. And past history shows that
demodularization (i.e. switching of modular content back to non-modular
rpms) is surprisingly complex, so the decision to "enable" cannot be
undone easily. Thus the discussion we're having now about the choices
> It remains unclear to me why Fedora would go out of its way to
> disallow usage of default streams in ELN. I understand they can
> present some issues if used incorrectly, or for something that is core
> to non-modular content, but the concept of a default stream being
> forbidden outright is strange. Default streams in ELN don't impact
> the wider Fedora distribution and removing them eliminates options and
> flexibility, forcing their usage to become a downstream-only concept
> which is exactly what we're trying to avoid with ELN to begin with.
Default streams in ELN definitely impact how RH packagers work with
ELN and rawhide. Roughly:
- if we have no default modules in rawhide or eln, work done in rawhide
translates 1:1 to eln and it seems likely packages can be just automatically
rebuilt for eln.
- if we have default modules in eln, and work is done first in rawhide,
then additional work is required to adapt the modules in eln.
If Fedora forbids default modules in ELN, then they'll have to do
additional work downstream in RHEL if that is the best choice there.
That is also bad.
(It *may* be possible to automatize this, but not as easily as
singular packages. And considering that non-modularized packages
need to be handled too, there will be at least two paths.)
- (hypothetically) if we have default modules in eln, and work is done
in those modules and skipping rawhide (for example by not building the
packages in rawhide), we have an unpleasant situation where eln and
This is a very tenuous strawman. You could also run into a case where
ELN forbids modules or default module streams and the maintainers
simply choose not to maintain anything in Fedora at all. That's far
worse than divergence in my opinion. Fortunately, I think neither are
actually likely and this part of the conversation seems like it's
pointless to debate.
Since the first scenario seems the most straightforward and pleasant
everyone involved, it is imho a good question whether there are technical
reasons to follow the second option.
And maybe that is the option most will choose. However, not even
letting ELN have the option seems to preclude that choice entirely.