Description of problem:after a successfull upgrade from mageia7 to mageia8 (4302 packages installed on 4303 downloaded ones), it reminds a lot of old packages mga7 (see list as attached file); what to do with them? have they their equivalent as mga8? would it be dangerous to remove then? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3.
Created attachment 12467 [details] rpm -qa |grep mga7
Thank you for this report. Are these orphans? If you do: # urpme --auto-orphans it will list orphans, and ask for confirmation before deleting them. OTOH if these M7 packages are *not* orphans, that is cause for concern.
CC: (none) => lewyssmith, ouaurelienSummary: after a successfull migration from mgeia7 to 8, it reminds a lot of ancient mga7 packages => after a successfull migration from mgeia7 to 8, there remain a lot of mga7 packagesStatus: NEW => NEEDINFO
You can remove all .mga7 packages as they are not necessary for running Mageia 8. Also, these packages should be uninstalled automatically upon upgrading.
I can confirm on my machine that many .mga7 packages remain after update to Mageia 8. It were nearly 200 packages. All of them had in common, that they had a complete namechange between MGA7->MG8 (not only version change). Thats maybe the reason why they don't get automatically removed. Examples: lib64mutter-private-gir4-3.32.1-2.mga7 -> lib64mutter-private-gir7-3.38.3-1.mga8 lib64yui9-3.4.2-1.mga7 -> lib64yui12-3.10.0-3.mga8 lib64ffi6-3.2.1-7.mga7 -> lib64ffi7-3.3-2.mga8 .... ....
CC: (none) => sturm-fr
CC: sturm-fr => (none)
The lib etc., packages are not uninstalled automatically as they may be required by third part packages that are not in the rpm db. That's intentional.
CC: (none) => davidwhodgins
I have removed all mga7 packages having their equivalents (superior version) as mga8 packages; nevertheless, it subsists a couple of packages mga7 having no equi valent as mga8: [alain4@mga6-64 ~]$ rpm -qa |grep mga7 python-slip-0.6.5-1.mga7 python2-six-1.12.0-3.mga7 python2-lxml-4.3.0-1.2.mga7 winexe-1.00-6.mga7 qt4-designer-plugin-webkit-4.8.7-26.2.mga7 libselinux-python-2.5-10.mga7 itext-core-2.1.7-37.mga7 python2-decorator-4.3.0-3.mga7 lib64compat-openssl10_1.1-1.0.2j-9.mga7 python-slip-dbus-0.6.5-1.mga7 is it possible to remove them without troubles?
(In reply to Lewis Smith from comment #2) > Thank you for this report. > Are these orphans? If you do: > # urpme --auto-orphans > it will list orphans, and ask for confirmation before deleting them. > OTOH if these M7 packages are *not* orphans, that is cause for concern. [root@mga6-64 alain4]# LANG=C urpme --auto-orphans writing /var/lib/rpm/installed-through-deps.list No orphans to remove
Hum these should be removed. Seems a packaging error not obsoleting earlier version. Python2 ones can be removed. Qt4 one also and winexe. lib64compat-openssl... must be removed because it will not see any further security patchs.
Created attachment 12470 [details] mga7 rpms left after urpmi online upgrade 7 -> 8 Howdy, Just a #METOO, in case something of value can be gleaned. My upgrade particulars are reported in https://bugs.mageia.org/show_bug.cgi?id=28485 Now, [rolf@x570i ~]$ cat /etc/release Mageia release 8 (Official) for x86_64 [rolf@x570i 8]$ rpm -qa | grep mga7 | wc -l 299 [rolf@x570i 8]$ rpm -qa | grep mga7 > old_rpms.txt # file attached Also, --auto-orphans doesn't look tractable, at my skill level, but: [rolf@x570i 8]$ sudo urpme --test --auto-orphans To satisfy dependencies, the following 736 packages will be removed (1.9GB): (orphan packages) PySolFC-2.10.1-1.mga8.noarch akonadi-mime-20.12.0-1.mga8.x86_64 aom-2.0.1-3.mga8.x86_64 arj-3.10.22-18.mga8.x86_64 audiocd-kio-20.12.0-1.mga8.x86_64 audiocd-kio-handbook-20.12.0-1.mga8.noarch baloo-widgets-20.12.0-1.mga8.x86_64 blueberry-1.4.1-1.mga8.noarch bluez-tools-0.2.0-0.git20190428.3.mga8.x86_64 bouncycastle-1.67-1.mga8.noarch bouncycastle-mail-1.67-1.mga8.noarch bouncycastle-pkix-1.67-1.mga8.noarch dbus-sharp-glib1.0-0.5.0-5.mga8.noarch dbus-sharp1.0-0.7.0-5.mga8.noarch dolphin-20.12.0-6.mga8.x86_64 ... urpmi-debuginfo-install-10.1-5.mga8.noarch virtualbox-kernel-5.10.12-desktop-1.mga7-6.1.18-4.mga7.x86_64 virtualbox-kernel-5.10.16-desktop-1.mga8-6.1.18-16.mga8.x86_64 virtualbox-kernel-5.7.14-desktop-1.mga7-6.0.24-4.mga7.x86_64 wmctrl-1.07-14.mga8.x86_64 x11-font-adobe-100dpi-1.0.3-9.mga8.noarch xarchiver-0.5.4.17-1.mga8.x86_64 xfce4-screensaver-4.16.0-1.mga8.x86_64 xpdf-4.03-1.mga8.x86_64 xpdf-common-4.03-1.mga8.x86_64 xsp-4.7.1-2.mga8.x86_64 zchunk-1.1.9-1.mga8.x86_64 Remove 736 packages? (y/N) FWIW. Thanks!
CC: (none) => rolfpedersen
Thanks for all the feedback & ideas. (In reply to sturmvogel from comment #4) > I can confirm on my machine that many .mga7 packages remain after update to > Mageia 8. It were nearly 200 packages. All of them had in common, that they > had a complete namechange between MGA7->MG8 (not only version change). Thats > maybe the reason why they don't get automatically removed. Good thinking. Perhaps something we should consider when doing upgrades. (In reply to peter lawford from comment #6) > I have removed all mga7 packages having their equivalents (superior version) > as mga8 packages; nevertheless, a few packages mga7 remain > (In reply to Dave Hodgins from comment #5) > The lib etc., packages are not uninstalled automatically as they may be > required > by third part packages that are not in the rpm db. That's intentional. Surely such packages would show as orphans (as far as Mageia is concerned)? (In reply to Rolf Pedersen from comment #9) > [rolf@x570i 8]$ rpm -qa | grep mga7 | wc -l > 299 > [rolf@x570i 8]$ sudo urpme --test --auto-orphans > To satisfy dependencies, the following 736 packages will be removed (1.9GB): > Remove 736 packages? (y/N) What to do? Orphans are easily removed all in one go; but other M7 residual pkgs need to be individually removed. With these large numbers, I would be tempted (if one can) to backup the entire Mageia 8 partition, then delete everything orphan/M7, and see whether it still works. If it does, good; if not - restore the backup. This is not something to recommend to every user. It is a sort of test to gain experience of these things to discover to what extent one can recommend chucking out left-overs. And another aspect to consider for future upgrading.
(In reply to Lewis Smith from comment #10) > What to do? Orphans are easily removed all in one go; but other M7 residual > pkgs need to be individually removed. > With these large numbers, I would be tempted (if one can) to backup the > entire Mageia 8 partition, then delete everything orphan/M7, and see whether > it still works. If it does, good; if not - restore the backup. > This is not something to recommend to every user. It is a sort of test to > gain experience of these things to discover to what extent one can recommend > chucking out left-overs. > And another aspect to consider for future upgrading. # rpm -qa |grep mga7 >urpme-mga7 Use an editor with regex support, such as mc to replace all $ by " \". I.E. append " \" to the end of every line. Manually add a line at the top with "urpme \", and remove the trailing " \" from the very last line in the file. Save the file. # . urpme-mga7 If there are specific packages I'm not ready to delete, I can just remove them from the file before sourcing it for execution. In mcedit, to add the " \", ensure the cursor is at the beginning of the file; press f4 (for replace); type $ in the search string field, " \" tab to the replacement string field and type in space backslash; cursor down until the cursor is over the ( ) in front of Regular expresion; press the space bar to select the use of a Regualr expression; cursor down until OK is highlighted; press enter; press cursor down or right to highlight ALL instead of Replace; press enter to process the edit.
(In reply to Aurelien Oudelet from comment #8) > Hum these should be removed. Seems a packaging error not obsoleting earlier > version. > > Python2 ones can be removed. > Qt4 one also and winexe. lib64compat-openssl... must be removed because it > will not see any further security patchs. While lib64compat-openssl will not receive updates, it should not be obsoleted as it may be needed for third party software, should the user choose to accept the security risks. Leaving it installed if unused poses no security risk since the lib will simply not be used by Mageia packages.
(In reply to Rolf Pedersen from comment #9) > [rolf@x570i 8]$ sudo urpme --test --auto-orphans > To satisfy dependencies, the following 736 packages will be removed (1.9GB): > (orphan packages) > dolphin-20.12.0-6.mga8.x86_64 > Remove 736 packages? (y/N) Don't remove them. This is why extreme care must be taken when using the auto-orphans option. $ rpm -q --whatrequires dolphin task-plasma5-minimal-5.20.4-2.mga8 So what has happened to get to this state? At some point in the past, the choice was made to remove one of the packages shown by rpm -q --requires task-plasma5-minimal from that system, which (since --nodeps) wasn't used) also uninstalled the meta package task-plasma5-minimal making all of the packages it requires, that were not uninstalled, into orphans. Using auto-orphans will remove plasma from that system. To fix the system, Let's assume it's khelpcenter that is not wanted. Run "urpmi task-plasma5-minimal" to reinstall the previously uninstalled packages. Use "rpm -e --nodeps khelpcenter" to uninstall it again, but without uninstalling task-plasma5-minimal. Then "urpme --auto-orphans" can be used to remove any orphans that were only required by khelpcenter, assuming there are no other task packages that have been removed by other package removals.
(In reply to Dave Hodgins from comment #13) > (In reply to Rolf Pedersen from comment #9) > > [rolf@x570i 8]$ sudo urpme --test --auto-orphans > > To satisfy dependencies, the following 736 packages will be removed (1.9GB): > > (orphan packages) > > dolphin-20.12.0-6.mga8.x86_64 > > Remove 736 packages? (y/N) > > Don't remove them. This is why extreme care must be taken when using > the auto-orphans option. > $ rpm -q --whatrequires dolphin > task-plasma5-minimal-5.20.4-2.mga8 > > So what has happened to get to this state? At some point in the past, the > choice was made to remove one of the packages shown by > rpm -q --requires task-plasma5-minimal from that system, which (since > --nodeps) > wasn't used) also uninstalled the meta package task-plasma5-minimal making > all of the packages it requires, that were not uninstalled, into orphans. > Yes, I've always mistrusted --auto-orphans, at least since soon after I experienced its reputation over the years since I first used urpm in 2000. There is one non-conclusive clue of a backslide @ https://bugs.mageia.org/show_bug.cgi?id=28485#c14 and another theory, below. > Using auto-orphans will remove plasma from that system. > To fix the system, Let's assume it's khelpcenter that is not wanted. > Run "urpmi task-plasma5-minimal" to reinstall the previously uninstalled > packages. > Use "rpm -e --nodeps khelpcenter" to uninstall it again, but without > uninstalling > task-plasma5-minimal. Then "urpme --auto-orphans" can be used to remove any > orphans that were only required by khelpcenter, assuming there are no other > task packages that have been removed by other package removals. [rolf@x570i ~]$ rpm -q task-plasma5-minimal package task-plasma5-minimal is not installed [rolf@x570i ~]$ sudo urpmi task-plasma5-minimal To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") elisa 20.12.0 1.mga8 x86_64 (recommended) elisa-handbook 20.12.0 1.mga8 noarch (recommended) task-plasma5-minimal 5.20.4 2.mga8 noarch 3.5MB of additional disk space will be used. 1.8MB of packages will be retrieved. Proceed with the installation of the 3 packages? (Y/n) Looking at the info for elisa, I see there is a classification, organization, and, more odious, indexing of all my music files, none of which do I desire, especially the indexing. [rolf@x570i ~]$ du -sh /music 40G /music My second theory is that I encountered this probably resource-consuming indexing and sought to remove elisa, task-plasma5-minimal falling as the latest victim of my storied "frantic hammering" IT style. At any rate, I went ahead with the installation and, before removing elisa* with --nodeps, tried the --auto-orphans switch. [rolf@x570i ~]$ sudo urpme --test --auto-orphans To satisfy dependencies, the following 683 packages will be removed (1.8GB): Then, [rolf@x570i ~]$ sudo rpm -e --nodeps elisa-handbook elisa [rolf@x570i ~]$ rpm -qa | grep elisa [rolf@x570i ~]$ sudo urpme --test --auto-orphans writing /var/lib/rpm/installed-through-deps.list To satisfy dependencies, the following 683 packages will be removed (1.8GB): Well, I'd say there's been some improvement to my system and will have to be happy with status quo or fresh install, at some point, or, possibly, follow Lewis's strategy in Comment 10. That I will leave for when I have more idle time (no exigent problems @ MGA8 ATM), perhaps if I fall off the wagon. ;) Thanks, Dave! Thanks, Lewis!
(In reply to sturmvogel from comment #4) > I can confirm on my machine that many .mga7 packages remain after update to > Mageia 8. It were nearly 200 packages. All of them had in common, that they > had a complete namechange between MGA7->MG8 (not only version change). Thats > maybe the reason why they don't get automatically removed. Examples: > > lib64mutter-private-gir4-3.32.1-2.mga7 -> > lib64mutter-private-gir7-3.38.3-1.mga8 > lib64yui9-3.4.2-1.mga7 -> lib64yui12-3.10.0-3.mga8 > lib64ffi6-3.2.1-7.mga7 -> lib64ffi7-3.3-2.mga8 > .... > .... How this can be handled by urpmi?
Assignee: bugsquad => mageiatoolsSource RPM: (none) => urpmi-8.125-1.mga8.src.rpm
CC: lewyssmith => (none)
CC: (none) => fri
(In reply to Aurelien Oudelet from comment #15) > (In reply to sturmvogel from comment #4) > > I can confirm on my machine that many .mga7 packages remain after update to > > Mageia 8. It were nearly 200 packages. All of them had in common, that they > > had a complete namechange between MGA7->MG8 (not only version change). Thats > > maybe the reason why they don't get automatically removed. Examples: > > > > lib64mutter-private-gir4-3.32.1-2.mga7 -> > > lib64mutter-private-gir7-3.38.3-1.mga8 > > lib64yui9-3.4.2-1.mga7 -> lib64yui12-3.10.0-3.mga8 > > lib64ffi6-3.2.1-7.mga7 -> lib64ffi7-3.3-2.mga8 > > .... > > .... > > How this can be handled by urpmi? It should not be handled by urpmi. The user may have third party software that requires the modules in those lib packages or requires old packages that are not lib packages. The third party software may be compiled from source, or manually copied binary files, not installed using rpm. As long as the old packages do not interfere with the new packages, we have to let users choose which old packages they do not need.
See Also: (none) => https://bugs.mageia.org/show_bug.cgi?id=28731
From comment 16 - thank you Dave :) https://wiki.mageia.org/en/Mageia_8_Errata#Unused_packages Describing why it is this way for more comments see bug 28731
Keywords: (none) => IN_ERRATA8
(In reply to Dave Hodgins from comment #16) > (In reply to Aurelien Oudelet from comment #15) > > > > How this can be handled by urpmi? > > It should not be handled by urpmi. The user may have third party software > that > requires the modules in those lib packages or requires old packages that are > not > lib packages. The third party software may be compiled from source, or > manually > copied binary files, not installed using rpm. > > As long as the old packages do not interfere with the new packages, we have > to > let users choose which old packages they do not need.
Resolution: (none) => WONTFIXStatus: NEEDINFO => RESOLVED
*** Bug 32291 has been marked as a duplicate of this bug. ***