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
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...)