On Tue, 14 Jan 2020 at 07:55, Neal Gompa <ngompa13@xxxxxxxxx> wrote: > > On Tue, Jan 14, 2020 at 6:01 AM Petr Pisar <ppisar@xxxxxxxxxx> 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. _______________________________________________ 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
