Re: Modularity and the system-upgrade path

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Oct 16, 2019 at 1:19 PM Przemek Klosowski via devel
<devel@xxxxxxxxxxxxxxxxxxxxxxx> wrote:
>
> On 10/15/19 9:26 PM, Stephen Gallagher wrote:
> > Module stream metadata would gain two new optional attributes,
> > "upgrades:" and "obsoletes:".
> >
> > If the "upgrades: <older_stream>" field exists in the metadata, libdnf
> > should switch to this stream if the following conditions are met:
> > 1) Changing the stream would not introduce conflicts.
> > 2) The stream is marked as `default_enabled` or `dep_enabled`.
> >
> > The "obsoletes: <older_stream>" field would be stronger. Its use
> > should require a special exemption (with a strong justification) and
> > it would cause libdnf to switch from that stream to this one
> > *unconditionally*  (failing the transaction if that transition would
> > cause conflicts). This would essentially be an "emergency escape" if
> > we need it.
>
> Modularity has multiple use cases: your proposal addresses the OS usage
> where modularity manages installed distribution's dependency versioning
> issues. What would happen if someone installed certain module stream to
> manage their own version requirements? Presumably, they might want to
> _never_ change the stream. How is that handled in your scheme? I think
> the "upgrades:" case would be fine, because explicit installation would
> not have the "default_enabled" attribute. However, if a new module
> declared the "obsoletes:", it would replace them no matter what. Would
> there be a way to prevent that, or are you arguing that such override
> should not be allowed?

I'm saying that the policy should forbid the use of that feature
except for an absolute emergency, requiring approval from FESCo or
similar. It would exist for cases like "Oh crap, it turns out we've
been shipping patented content in this stream and we're obligated to
remove it" or something like that. It should never be used in the
general case. Not even for "This is so old we should force upgrades".
For that we should just drop the stream entirely from the next
release, which would result in the upgrade being impossible until the
user took a manual action to get off that stream.

It would be my hope that the "obsoletes:" would never actually get
used, but I'm generally in favor of planning for the worst case ahead
of time if we can see it coming.
_______________________________________________
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




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux