| Summary: | after a successful upgrade mga8 to mga9 it remains a lot of mga8 pkgs | ||
|---|---|---|---|
| Product: | Mageia | Reporter: | peter lawford <petlaw726> |
| Component: | RPM Packages | Assignee: | Mageia Bug Squad <bugsquad> |
| Status: | RESOLVED DUPLICATE | QA Contact: | |
| Severity: | normal | ||
| Priority: | Normal | CC: | davidwhodgins |
| Version: | 9 | ||
| Target Milestone: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Source RPM: | CVE: | ||
| Status comment: | |||
| Attachments: |
return of rpm -qa |grep mga8
return of dnf autoremove |
||
|
Description
peter lawford
2023-09-16 14:01:33 CEST
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 =>
RESOLVED (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 |