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
for ELN.
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.
(It *may* be possible to automatize this, but not as easily as with
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
rawhide diverge.
Since the first scenario seems the most straightforward and pleasant for
everyone involved, it is imho a good question whether there are technical
reasons to follow the second option.
Zbyszek