Re: How to obsolede module?
On Tue, 2020-01-14 at 08:13 -0500, Stephen John Smoogen wrote:
On Tue, 14 Jan 2020 at 07:55, Neal Gompa <ngompa13(a)gmail.com>
wrote:
> On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar(a)redhat.com> wrote:
> > On Tue, Jan 14, 2020 at 05:21:40AM -0500, Josef Ridky wrote:
> > > Hi folks,
> > >
> > > Does anyone know, how can I obsolete modular version of package?
> > >
> > > TL;DR
> > >
> > > I have one package (gimp) that is now available as RPM and Module at the
> > > same time in Fedora. Due of modular version makes issues to users during
> > > system upgrade, I've decided to remove (obsolete) modular version of
gimp
> > > and keep the RPM version only.
> > >
> > > Question is, How can I set new RPM build to be the replacement for the
> > > modular one? Especially, is it possible, when someone with modular gimp
> > > installed types `dnf upgrade gimp`, that command will remove modular gimp
> > > and installs new RPM instead?
> > >
> > RPM Obsolets triggers a package removal and can be placed into any package.
> > However, you cannot obsolete a module (i.e. disable or reset it)
> > programatically. This is by design an action that needs an explicit user's
> > consent. If you need modularity to support marking modules end-of-life,
> > I recommend you contacting Modularity team (psabata) that has been requested
> > to implement this feature for a long time.
> >
>
> I still can't believe that anyone thought this was okay... :(
>
It was a required feature to try and compromise between developers who
hated to maintain old stuff on old releases (and leave Fedora because
it is too slow) and sysadmins who have working stuff and don't want it
broken (and so don't use Fedora because it is so fast).
Take for example a system with a working python36 or php-7.1 stack
running websites. If the developer updates to php-7.2 because the
upstream has EOL'd that php version during a release cycle.. then
everything is broke. The idea is to allow the sysadmin the ability to
decide if php-7.2 is right for them and when while allowing the
packager to get the newer version out sooner.
This is fine, but then modules should have never been possible to
install unintentionally, we already discussed that though. This is the
afterglow of that unfortunate explosive decision (to allow normal
packages to drag in modules) :-)
--
Simo Sorce
RHEL Crypto Team
Red Hat, Inc