Bug 28601

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, ouaurelien
Summary: 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 packages
Status: 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

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 => mageiatools
Source RPM: (none) => urpmi-8.125-1.mga8.src.rpm

(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.

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) => WONTFIX
Status: NEEDINFO => RESOLVED

*** Bug 32291 has been marked as a duplicate of this bug. ***