Description of problem: The command urpme --auto-orphans doesn't work. Completely. It doesn't find any orphans. Simple test case: $ rpm -qa | grep devel libstdc++-devel-4.7.2-7.mga3 glibc-devel-2.17-5.mga3 $ sudo urpmi png-devel To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") lib64png-devel 1.5.13 2.mga3 x86_64 lib64png15_15 1.5.13 2.mga3 x86_64 lib64zlib-devel 1.2.7 7.mga3 x86_64 2MB of additional disk space will be used. 610KB of packages will be retrieved. Proceed with the installation of the 3 packages? (Y/n) http://mirror.yandex.ru/mageia/distrib/3/x86_64/media/core/release/lib64png15_15-1.5.13-2.mga3.x86_64.rpm http://mirror.yandex.ru/mageia/distrib/3/x86_64/media/core/release/lib64png-devel-1.5.13-2.mga3.x86_64.rpm http://mirror.yandex.ru/mageia/distrib/3/x86_64/media/core/release/lib64zlib-devel-1.2.7-7.mga3.x86_64.rpm installing lib64png-devel-1.5.13-2.mga3.x86_64.rpm lib64png15_15-1.5.13-2.mga3.x86_64.rpm lib64zlib-devel-1.2.7-7.mga3.x86_64.rpm from /var/cache/urpmi/rpms Preparing... ############################################# 1/3: lib64zlib-devel ############################################# 2/3: lib64png15_15 ############################################# 3/3: lib64png-devel ############################################# $ sudo urpme lib64png-devel removing lib64png-devel-1.5.13-2.mga3.x86_64 removing package lib64png-devel-2:1.5.13-2.mga3.x86_64 1/1: removing lib64png-devel-2:1.5.13-2.mga3.x86_64 ############################################# $ sudo urpme --auto-orphans No orphans to remove $ In this case lib64png15_15 and lib64zlib-devel had to be marked as orphans but it had not happen. Neither first 'urpme lib64png-devel' command nor 'urpme --auto-orphans' displayed them as unneeded. This happens on a 'host' x86_64 system with updates_testing repos enabled and in chroot i586/x86_64 environments with only official release/updates repos enabled. Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Reproducible: Steps to Reproduce:
CC: (none) => olegbosis
Summary: urpme --auto-orphans doesn't work => urpme --auto-orphans doesn't work with png-develSource RPM: (none) => urpmi ?
You have changed the title to the wrong one. First I've noticed that now it happens only in chroots (tested with simple 'chroot' and 'schroot' commands). I can not reproduce it in my host system anymore. And second the command doesn't work completely with devel packages and also doesn't work with some other packages. I do build packages for Mageia Russian Community repository and I can not reuse my chroots because of this bug: all packages installed with 'urpmi --buildrequires' can not be uninstalled as orphans after building my package. And another example from 32-bit chroot: $ sudo urpmi cmake To satisfy dependencies, the following packages are going to be installed: Package Version Release Arch (medium "Core Release") cmake 2.8.10.2 5.mga3 i586 libarchive12 3.0.4 3.mga3 i586 25MB of additional disk space will be used. 3.8MB of packages will be retrieved. Proceed with the installation of the 2 packages? (Y/n) http://mirror.yandex.ru/mageia/distrib/3/i586/media/core/release/libarchive12-3.0.4-3.mga3.i586.rpm http://mirror.yandex.ru/mageia/distrib/3/i586/media/core/release/cmake-2.8.10.2-5.mga3.i586.rpm installing cmake-2.8.10.2-5.mga3.i586.rpm libarchive12-3.0.4-3.mga3.i586.rpm from /var/cache/urpmi/rpms Preparing... ############################################# 1/2: libarchive12 ############################################# 2/2: cmake ############################################# $ sudo urpme cmake removing cmake-2.8.10.2-5.mga3.i586 removing package cmake-1:2.8.10.2-5.mga3.i586 1/1: removing cmake-1:2.8.10.2-5.mga3.i586 ############################################# $ sudo urpme --auto-orphans No orphans to remove $ And again the problem with libarchive12 that is not an orphan after removing cmake.
Summary: urpme --auto-orphans doesn't work with png-devel => urpme --auto-orphans doesn't work in chroots
Mga3 is EOL in a few days. Can you reproduce the issue on Mga4?
Keywords: (none) => NEEDINFOCC: (none) => thierry.vignaud
(In reply to Thierry Vignaud from comment #2) > Mga3 is EOL in a few days. > Can you reproduce the issue on Mga4? No. It's a bug specific to mga3 only.
Sorry, won't fix
Status: NEW => RESOLVEDResolution: (none) => OLD