On Tue, Jun 23, 2020 at 7:36 AM Miro Hrončok <mhroncok(a)redhat.com> wrote:
On 23. 06. 20 13:29, Josh Boyer wrote:
>> (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.
> 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.
When ELN was proposed and discussed, separate eln branches were proposed by
several Fedora and RHEL maintainers. It was dismissed, and it was said
repeatedly that rawhide/ELN divergence MUST be avoided. I wonder if that
requirement has changed.
Divergence where? At the source level? Why would the existence of a
default module in ELN cause divergence at the source level? It
wouldn't. The rawhide sources would be used for the module build in
If you mean at the binary level, then I have no idea how anyone
possibly thinks ELN and Rawhide are the same because ELN is built with
entirely different flags, settings, etc.
> Fortunately, I think neither are
> actually likely and this part of the conversation seems like it's
> pointless to debate.
This has happened in the past when Fedora had default modular streams. Whether
likely or not to repeat, we have experience with the problem, so the discussion
is not pointless at all.
You seem to be concerned less about divergence and more about
abandonment of packages in Fedora, at least in ways counter to how the
default distribution is built. You could come up with some guidelines
on usage of ELN modules that require existing content to be maintained
as it is in Fedora if that's what you want to ensure. It's onerous
and causes extra work, but allows people to do their work in the open.
However, if you prevent that from happening entirely, you run the risk
of them abandoning the packages entirely which is counter to your goal