On Tue, 2020-01-14 at 08:13 -0500, Stephen John Smoogen wrote: > On Tue, 14 Jan 2020 at 07:55, Neal Gompa <ngomp...@gmail.com> wrote: > > On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppi...@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 _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@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/devel@lists.fedoraproject.org
