On Mon, May 11, 2020 at 01:47:32AM +0200, Miro Hrončok wrote: > On 10. 05. 20 20:48, Kevin Fenzi wrote: > >Basically we are switching from 'I go and install > >fedora-obsolete-packages and have opted in to it' to 'I have to go > >explictly exclude it to keep my obsolete packges'. > > As others have pointed out, this was never the case of 'I go and > install fedora-obsolete-packages and have opted in to it' -- this > was always the case of 'fedora-obsolete-packages obsoletes something > I had installed, so it is pulled in by dep resolver'. > > Is this ideal? No. But it has not been changed. (The changed part is > fedora-obsolete-packages does not get installed in the process.) > > A better solution to the problem fedora-obsolete-packages is trying > to solve would be to use allowerasing on system-upgrade, but that is > another can of worms, because it also removes packages that have > broken dependencies, but were not intentionally removed. I think you mean "different", not "better" here ;) > The idea solution IMHO would be to allow erasing only the packages > that do not belong to a distupgrade repository. Possibly to have > that option only for the Fedora repos, so packages installed from a > thrid-party would not get erased. I don't think that is a good solution either. The problem is that one guy's leftover package is part of another gal's important application stack. Instead of trying to divine whether a package is important based on source metadata, IMHO it would be better to make the user interface stronger: have dnf say what is removed and why (when obsoleted), and when packages block the upgrade path, offer an option to autoremove *a specific package*. (Right now, the user has to first remove some package by 'dnf remove', and then they can re-run the upgrade, to see if that resolved the issues. There is no guarantee that the removal of the package they removed actually is enough to upgrade successfully.) I'd imagine the following workflow: $ dnf upgrade --releasever=33 ... list of conflicts ... Try --allow-erasing=foo to remove foo on conflicts $ dnf upgrade --releasever=33 --allow-erasing=foo (here dnf would try the upgrade with considering of foo removal) ... The advantage is that the user has a change to think whether foo is something that they can do without, or alternatively just write it down on the list of packages to reinstall after update. Maybe even the following would work: $ dnf upgrade --releasever=33 --allow-erasing='*.fc28.*' (consider removal of any very old package...) Zbyszek _______________________________________________ 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
