Description of problem: after a successful upgrade of my system, named mga6-64, from mga8 to mga9: [alain4@mag6 ~]$ rpm -qa |grep mga8 > postupgrade_mga8pkgs_mga6-64.txt (see attached file) it remains many, many mga8 pkgs; what to do with these? for information, my only non-mageia pkgs are: [alain4@mag6 ~]$ urpmq --not-available vivaldi-stable-6.2.3105.48-1.x86_64 google-chrome-stable-117.0.5938.88-1.x86_64 skypeforlinux-8.103.0.208-1.x86_64 opera-stable-102.0.4880.56-0.x86_64 google-earth-pro-stable-7.3.6.9345-0.x86_64 Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 13994 [details] return of rpm -qa |grep mga8
You filed these bug already several times. See the answers in bug 28731 and bug 28601. *** This bug has been marked as a duplicate of bug 28601 ***
Status: NEW => RESOLVEDResolution: (none) => DUPLICATE
and some more from you... bug 21492 bug 25326
(In reply to sturmvogel from comment #2) > You filed these bug already several times. See the answers in bug 28731 and > bug 28601. > > *** This bug has been marked as a duplicate of bug 28601 *** thank you for replying to the bug 32291; the question is: is any mga(n+1) package dependant on some mga(n) package? if the answer is no, that means it'possible to uninstall all mga(n) pkgs after upgrade mga(n) > mga(n+1) without trouble if yes there is a concern somewhere; I should wish to have the answer to this question from all I've read, I consider that urpme --auto-orphans is not really reliable and its thoughtless use can lead to severe problems Best regards to all
surprisingly: [root@mga6-64 alain4]# LANG=C urpme --auto-orphans No orphans to remove this means that the hundreds of remaining mga8 pkgs are not considered as orphans, but: [root@mga6-64 alain4]# dnf autoremove > dnf_autoremeove.txt see attached file one can see that a couple of mga8 (but far from all) and mga9 too are considered as to be removed; what to do?
Created attachment 13995 [details] return of dnf autoremove
The same comments as in the other bugs apply. As the version number is part of the package name, and the version number increased, the mga8 packages didn't get removed as the "new" mga9 package has another name. Every Mga8 package which has a Mga9 equivalent can be removed... You can check this easily yourself with the list of your comment #1 lib64boost_nowide1.75.0-1.75.0-1.mga8 -> lib64boost_nowide1.81.0-1.81.0-3.mga9 lib64ebook-contacts1.2_3-3.38.3-2.mga8 -> lib64ebook-contacts1.2_4-3.48.3-1.mga9 lib64wacom2-1.7-2.mga8 -> lib64wacom9-2.7.0-1.mga9 and so on...
(In reply to peter lawford from comment #4) > (In reply to sturmvogel from comment #2) > > You filed these bug already several times. See the answers in bug 28731 and > > bug 28601. > > > > *** This bug has been marked as a duplicate of bug 28601 *** > > thank you for replying to the bug 32291; > > the question is: is any mga(n+1) package dependant on some mga(n) package? > if the answer is no, that means it'possible to uninstall all mga(n) pkgs > after upgrade mga(n) > mga(n+1) without trouble > if yes there is a concern somewhere; I should wish to have the answer to > this question > from all I've read, I consider that urpme --auto-orphans is not really > reliable and its thoughtless use can lead to severe problems Old lib packages are allowed as they may be needed for third party software that is not managed by urpmi. urpme does not distinguish between packages installed manually using rpm (bypassing urpmi) and packages left over from prior to an upgrade. There is no way to do so without causing problems for people who use third party software. The risk of using urpme --auto-orphans is clearly explained in the wiki page. https://wiki.mageia.org/en/Removing_packages#Warning
CC: (none) => davidwhodgins