How to obsolede module?

[Josef Ridky]

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?

Regards

Josef Ridky
Software Engineer
Core Services Team
Red Hat Czech, s.r.o.

[Kalev Lember]

Hi Josef,

As far as I know, it's not possible to do that right now in a generic way.
Right now it's best to avoid doing so in already released Fedora versions
(F30, F31) and only keep the changes for the next release (F32 rawhide).

The reason for this is that dnf (and libdnf that's used by PackageKit) does
not have a mechanism for migrating from modules to regular packages. We did
a hack to get a few modules correctly migrated back to regular packages for
distro upgrades to F31 (the hack is in F29 and F30 dnf and PackageKit).
It's possible that we need to repeat the hack for distro upgrades to F32;
but if this is so it's only for known module streams that are migrating in
F32.

There's a dnf ticket open where fesco is requesting a generic mechanism for
migrating modules to regular packages, but I don't know if this is going to
materialize in F32 timeframe.

So in short: don't do this in F30 and F31. It's fine to remove the module
in rawhide; dnf is going to do something during the distro upgrade to F32
to get users correctly migrated.

Hope this helps,
Kalev

On Tue, Jan 14, 2020 at 11:22 AM Josef Ridky <jridky(a)redhat.com&gt; 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?
>
>  Regards
>
>  Josef Ridky
>  Software Engineer
>  Core Services Team
>  Red Hat Czech, s.r.o.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail]
>

[Petr Pisar]

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.

Since any active module content masks same-named non-modular packages, you
cannot uninstall the modular gimp package by putting an Obsoletes into the
non-modular gimp package. Until the user explicitly disables the module, your
non-modular gimp will be invisible and thus the Obsoletes should not take any
effect.

But there is an solution in Fedora if your module exists in updates repository
only. Because Fedora mirrors keep only the latest module version, it should
be possible to place another package into the module, make it Obsolete and
Provide the modular gimp package. This causes DNF to replace the modular
gimp package with the another package. After that DNF should make the
non-modular gimp visible. Then you can release a non-modular gimp with higher
release than the Provided "gimp" symbol and that will obsolete the another
package. This should DNF make to replace the modular another package with your
non-modular gimp package.

But this only a theory. Maybe it won't work because of a caching of the
modular metadata somewhere.

-- Petr

[Neal Gompa]

On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar(a)redhat.com&gt; 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... :(

>  Since any active module content masks same-named non-modular
> packages, you
>  cannot uninstall the modular gimp package by putting an Obsoletes into the
>  non-modular gimp package. Until the user explicitly disables the module, your
>  non-modular gimp will be invisible and thus the Obsoletes should not take any
>  effect.
>
>  But there is an solution in Fedora if your module exists in updates repository
>  only. Because Fedora mirrors keep only the latest module version, it should
>  be possible to place another package into the module, make it Obsolete and
>  Provide the modular gimp package. This causes DNF to replace the modular
>  gimp package with the another package. After that DNF should make the
>  non-modular gimp visible. Then you can release a non-modular gimp with higher
>  release than the Provided "gimp" symbol and that will obsolete the another
>  package. This should DNF make to replace the modular another package with your
>  non-modular gimp package.
>
>  But this only a theory. Maybe it won't work because of a caching of the
>  modular metadata somewhere.
>  
This theory doesn't work if your module had defaults because all the
YAML documents are downloaded and applied to DNF locally. If it
didn't, then it'd work.



-- 
真実はいつも一つ！/ Always, there's only one truth!

[Stephen John Smoogen]

On Tue, 14 Jan 2020 at 07:55, Neal Gompa <ngompa13(a)gmail.com&gt; wrote:
>  On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar(a)redhat.com&gt; 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.



-- 
Stephen J Smoogen.

[Simo Sorce]

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&gt;
> wrote:
>  > On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar(a)redhat.com&gt; 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

[Dominik 'Rathann' Mierzejewski]

On Tuesday, 14 January 2020 at 11:21, 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. 
Thank you!

Regards,
Dominik
-- 
Fedora   https://getfedora.org  |  RPM Fusion  http://rpmfusion.org
There should be a science of discontent. People need hard times and
oppression to develop psychic muscles.
        -- from "Collected Sayings of Muad'Dib" by the Princess Irulan

[Simo Sorce]

On Tue, 2020-01-14 at 05:21 -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. 
Thank you,
without my knowledge my machine had acquired the modular version of
gimp, and wouldn't upgrade. I had to debug and finally remove the gimp
module and other things to be able to do a system upgrade.
The experience was annoying.

Not your fault, I think modularity is still very immature when it comes
to upgrades, so it shouldn't be used yet for very popular packages of
Fedora Workstation IMO.

>  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? 
Even if modularity does not allow this I hope a scriptlet can be
generated that could deal with this as a final module upgrade...

>  
>  Regards
>  
>  Josef Ridky
>  Software Engineer
>  Core Services Team
>  Red Hat Czech, s.r.o.
>  _______________________________________________
>  devel mailing list -- devel(a)lists.fedoraproject.org
>  To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
>  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/[e-mail] 
-- 
Simo Sorce
RHEL Crypto Team
Red Hat, Inc