On Tue, Jun 16, 2020 at 12:46:30AM +0200, Miroslav Suchý wrote:
Can you give example?
I have a F30 system running the F29 mailgraph package, which was
retired. It was the last remaining blocker preventing that system from
being upgraded to F31. (The others were due to non-fedora-packaged
deprecated perl stuff..)
(I have since rebuilt the package for F31, and I will be using that
self-maintained package instead of having to come up with something to
replace mailgraph's functionality. Not to mention historical data..)
> What about software installed from 3rd-party repositories? What
> packages that were downloaded and installed directly from ISVs?
Should not be affected.
So why would software supplied by fedora be treated differently than
PlayOnLinux - this is a piece of SW I used to use. It caused an issue
during upgrade to F32 and it has been added to
fedora-obsolete-packages. Yet, when DNF told me it has to be removed,
I reacted "WTF, I am using it". I looked up the information and then I
made an informed decision.
So did you make the informed decision to not upgrade, or to remove it
(playonlinux was one of the many casualties of the python2 retirement
debacle. Not Fedora's fault..)
libgltf - This is actually a random package with *fc29* on my
workstation. Hmm, one moment - yeah, dead package. I do not even know
what it does, why it happened to be on my computer. Hmmm, yes -
nothing requires it. It can be safely removed. And it is gone. Is it
Yup; you made that decision -- because DNF couldn't have known if you
needed it or not -- this is especially true for a leaf library. What if
you had some software you'd compiled from source that relied on that
By all means, let's obsolete stuff that has proper replacements (eg
library or package renames) but auto-removing software simply because
fedora no longer packages it is not user-friendly and leads to
And yes, I know the 'dnf system-upgrade download' output will list stuff
it's removing, but it's all too easy to miss something in that 3000-odd
line dump. I consider an explicit error to be far more informative,
although I suppose splitting apart those "retired packages causing
conflicts" packages into a separate list on the system-upgrade output
would IMO be a much better approach.
(Did I miss when Fedora changed their policies to auto-remove
applications or libraries simply because they're no longer packaged?
The python2->3 debacle notwithstanding...)
Solomon Peachy pizza at shaftnet dot org (email&xmpp)
@pizza:shaftnet dot org (matrix)
High Springs, FL speachy (freenode)