Description of problem:after upgrading a mgeia7 system with mgaapplet method it stays 318 orphans among them mga8 pkgs which could be surprising and 255 mga7 pkgs are not purged: see attached files Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 12586 [details] return of urpme--auto-orphans
Created attachment 12587 [details] return of rpm -qa |grep mga7
This seems like a duplicate from Bug 28601 https://bugs.mageia.org/show_bug.cgi?id=28601
(In reply to sturmvogel from comment #3) > This seems like a duplicate from Bug 28601 > https://bugs.mageia.org/show_bug.cgi?id=28601 not entirely, because here is provided the list of orphans unlike bug 28601
This is duplicate, sorry. But I will answer. For mga7 packages: See Dave Hodgins answer here: https://bugs.mageia.org/show_bug.cgi?id=28601#c16 Feel free to remove all of them. = lib name changes and old packages that urpmi leaves because of possibly desired by 3rd party installed softwares. Same for python2 packages. In mga8 RPM, lot of under-the-hood packages like wxgtk. For lib64gnome-keyring0-3.12.0-12.mga8.x86_64 lib64gnome2_0-2.32.1-21.mga8.x86_64 lib64gnomeui2_0-2.24.5-13.mga8.x86_64 What desktop do you use? Plasma?
CC: (none) => ouaurelien
I think these two bugs are the same; that this should be marked duplicate of the other - despite the extra orphan evidence here; and both be added to the upgrade tracker bug. The other to be assigned to mageiatools. Await agreement about this before acting!
CC: (none) => lewyssmith
Dave's answer in the other bug is very good. I am pondering to add a note like that in Errata. User may have i.e third party programs that depend on the packages but they are still marked orphans. Maybe some packaging is less than ideal and can be improved - in that case they should have separate bugs. So far I believe urpmi does this right.
CC: (none) => fri
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=28601
Also, keep in mind that while the mga7 orphans are kept just in case the user needs them for things rpm doesn't know about, the corresponding mga8 packages are installed for those orphans, which is why there are mga8 orphans too.
CC: (none) => davidwhodgins
While I see the sense of these remarks - indeed, like the idea -, why are we seeing hundreds of these .mga7 & .mga8 things? And not just PL.
(In reply to Dave Hodgins from comment #8) > the corresponding mga8 packages > are installed for those orphans, which is why there are mga8 orphans too. Thanks, added that info too to Errata
Keywords: (none) => IN_ERRATA8
(In reply to Lewis Smith from comment #9) > While I see the sense of these remarks - indeed, like the idea -, why are we > seeing hundreds of these .mga7 & .mga8 things? And not just PL. Not sure what you mean by PL. During the use of mga7, many updates would have been installed bringing in new lib packages. The old ones are not removed as they may be needed, becoming orphans. Even on a new install, there will be multiple versions of some packages installed as being suggested by different packages. These packages are not required, just suggested or recommended, so are orphans from the moment they are installed. During upgrade, all versions of the Mageia 7 packages that don't get deleted (lib, python, etc) become orphans. Regards, Dave Hodgins
(In reply to Morgan Leijström from comment #10) > (In reply to Dave Hodgins from comment #8) > > the corresponding mga8 packages > > are installed for those orphans, which is why there are mga8 orphans too. > > Thanks, added that info too to Errata Please also add, that packages that another package suggests or recommends that get installed too, are not strictly required, so are orphans even though newly installed.
Done https://wiki.mageia.org/en/Mageia_8_Errata#Unused_packages I begin to feel the info should get incorporated somewhere in wiki about how urpmi works. Yes maybe the URPMI page. But i guess DNF works the same.
I'm not an expert in how rpm works. My understanding from observation ... An orphan is any package that hasn't been explicitly listed in an install request, or isn't required by a package that has been explicitly listed in an install request. From "man rpm" ... Dependencies: [--conflicts] [--enhances] [--obsoletes] [--provides] [--recommends] [-R,--requires] [--suggests] [--supplements] conflicts and obsoletes prevent packages that interfere with each other from being installed on the same system, including older versions of the same package. enhances, I've never noticed in use. Not really sure what it is for. Provides helps find wanted packages by a feature other then it's name. It's mostly used where more than one package can be used for the same purpose, and when using urpmi/dnf interactively, is used to create the list where the user has to select which one they want. requires lists the packages or features that a package must have present in the system for it to work. When a package is removed, those other packages become orphans. supplements, like enhances, I've never noticed in use. suggests and recommends (I don't know the difference) will cause additional packages to be installed. My understanding is they are orphans as soon as they are installed, since they have not been explicitly selected, or required by an explicitly requested package. I may be wrong on this part.
Do we know how many orphans there were in the M7 systems prior to upgrading them? This seems basic information to put into perspective ideas about why there are so many post-upgrade.
In my testing, I ensure there are none before I start the upgrade. I expect them post upgrade, so don't keep track of how many there are after.
(In reply to Dave Hodgins from comment #8) > Also, keep in mind that while the mga7 orphans are kept just in case the user > needs them for things rpm doesn't know about, the corresponding mga8 packages > are installed for those orphans, which is why there are mga8 orphans too. orphaned RPM should be removed by hand, not automatically by a script. For mga8 packages, they should not orphaned as soon as they are installed. But, it is possible that is due to updates already released.
Status: NEW => RESOLVEDResolution: (none) => WONTFIX
(In reply to Aurelien Oudelet from comment #17) > For mga8 packages, they should not orphaned as soon as they are installed. > But, it is possible that is due to updates already released. For mga7 packages with corresponding mga8 packages, the mga8 packages will be installed. If the mga7 packages were orphans, the mga8 packages will be orphans too, immediately upon installation. Same thing if in mga7 the package was required by some other package, and in mga8 it is no longer required, for example if a requires in a mga7 package was removed or changed to a suggests in the mga8 version of the package. So while it may indicate a problem (check the log for errors), in most cases it is normal.