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 about 
> > packages that were downloaded and installed directly from ISVs?
> 
> Should not be affected.

So why would software supplied by fedora be treated differently than 
third-party software?  

> 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 
anyway?

(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 
library?

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 
unpleaseant surprises.

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
-- 
Solomon Peachy                        pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
High Springs, FL                      speachy (freenode)

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

Reply via email to