On Fri, Oct 4, 2019 at 9:32 PM Miro Hrončok <mhroncok@xxxxxxxxxx> wrote:
>
> On 04. 10. 19 16:57, Stephen Gallagher wrote:
> > Right now, there are two conflicting requirements in Fedora Modularity
> > that we need to resolve.
> >
> > 1. Once a user has selected a stream, updates should follow that
> > stream and not introduce incompatiblities. Selected streams should not
> > be changed without direct action from the user.
> > 2. So far as possible, Modularity should be invisible to those who
> > don't specifically need it. This means being able to set default
> > streams so that `yum install package` works for module-provided
> > content.
> >
> > Where this becomes an issue is at system-upgrade time (moving from
> > Fedora 30->31 or continuously tracking Rawhide). Because of
> > requirement 1, we cannot automatically move users between streams, but
> > in the case of release upgrades we often want to move to a new default
> > for the distribution.
>
>
> Wouldn't it be easier if the "default stream" would just behave like a regular
> package?
>
> I can think of two solutions of that:
>
> 1. (drastic for modular maintainers)
>
> We keep miantaining the default versions of things as ursine packages. We only
> modularize alternate versions.
>
> Pros: Users who don't want alternate versions won't be affected by imperfections
> of our modular design. No Ursa Major/Prime needed in the buildroot.
>
> Cons: Modular maintainers who do modules with just one stream because it is
> easier for them would need to rollback to what's easier for everybody else but
> them. Modular maintainers who do multiple modular streams would need to maintain
> both the alternate streams and ursine packages.
I think this is the best way forward, and I don't think it's "drastic"
for maintainers. They *already* maintain a default branch, for which
similar Packaging / Update Guidelines apply than for non-modular
packages. They could even use a package.cfg file to automatically
build stuff for multiple fedora branches ...
In my opinion, this is also the most "fair" approach, because it
doesn't shift the maintenance burden from one packager to *everyone
else*.
It results in the least disruption for users who want default versions
of things.
It means no more disruptions for packagers who rely on the packages in
question - they can just target the default ("ursine") versions.
Another benefit of this would be that the "*-modular" repositories
could be disabled by default, which would eliminate a whole lot of
upgrade issues for "normal users".
Only people who *actually want* alternate versions would enable
modules (and *-modular repos?), and they can then expected to know how
to handle upgrade issues.
> 2. (potentially dangerous consequences?)
>
> We put the default modular stream into our regular repos, similarly to what we
> try to do in the buildroot. "dnf install Foo" would install the Foo package and
> would not enbale any streams or modules. The modular maintainers would keep
> maintaining the modules as now, the infrastructure would compose the defaults
> into the regular repo (or an additional but default-enabled one).
>
> Pros: Maintainers would keep doing what they desire.
>
> Cons: We would need to make this technically possible and figure out all the
> corner cases (however AFAIK this needs to be done for the "modules in buildroot"
> thing as well).
I see some issues with this approach. For example, the modularized
Java packages dropped a whole lot of "cruft", which now makes these
packages slightly incompatible with the non-modular packages - this
includes dropping Epoch from packages, dropping subpackages without
obsoleting them, etc. This is probably not a problem for module
streams, but it definitely *is* a problem if such modular packages
start to get treated like "normal packages".
> WDYT?
I think that letting people drop ownership and maintenance of "normal
packages" and *only* doing modules instead was a mistake. But that's
just my opinion ;)
Fabio
> --
> Miro Hrončok
> --
> Phone: +420777974800
> IRC: mhroncok
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
