[arch-general] js60 update -- reveals older packages installed as deps not updated and left on system
All, I don't know if this is an old packaging problem, or if this is normal, but with the following updates: Packages (6) js60-60.6.3-1 linux-lts-4.19.44-1 linux-lts-headers-4.19.44-1 perl-net-http-6.19-1 polkit-0.116-1 tmux-2.9_a-2 I saw the: Net Upgrade Size: 53.68 MiB and thought I would investigate. Checking what 'js..' packages were installed I found: $ pmq | grep '^js' js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 js60 60.6.3-1 It was apparent that the size increase was due to the addition of js60 while js52 remained installed. (that may or may not be expected) That prompted the question Why are js17 and js still installed when neither are current packages? Checking community/js185 1.0.0-8 seems to be the "current" legacy package. Is this normal that new versions of packages are just added without removing the replaced package? I would have expected 'js' to be removed when `js17` was updated and then 'js17' to be removed when `js185` became available? Checking with pacman -Qi the reason `js` and `js17` were installed was as a dependency for another package: $ pmqi js Name : js Version : 24.2.0-4 Description : JavaScript interpreter and libraries <snip> Installed Size : 11.42 MiB Packager : Evangelos Foutras <evangelos@foutrelis.com> Build Date : Mon 07 Nov 2016 10:57:32 AM CST Install Date : Fri 25 Nov 2016 02:59:27 AM CST Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature $ pmqi js17 Name : js17 Version : 17.0.0-4 Description : JavaScript interpreter and libraries (legacy) Architecture : x86_64 <snip> Conflicts With : js<24.2.0 Replaces : None Installed Size : 8.39 MiB Packager : Bartłomiej Piotrowski <bpiotrowski@archlinux.org> Build Date : Mon 07 Nov 2016 06:19:43 AM CST Install Date : Fri 25 Nov 2016 02:59:06 AM CST Install Reason : Installed as a dependency for another package Install Script : No Validated By : Signature Further checking whether any of the old packages are required shows they are not, e.g. $ pacman -Qdt ... js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 ... So is this just one of those circumstances where you have to manually check if packages are no longer needed by the system and uninstall manually? It's not a big deal, but more a curiosity to understand when this type thing can occur in the normal process of just calling pacman -Syu. -- David C. Rankin, J.D.,P.E.
Hi, Le 18/05/2019 à 01:23, David C. Rankin a écrit :
Is this normal that new versions of packages are just added without removing the replaced package?
Yes, because they are not straight upgrade from previous version and often have incompatibilities so that both packages can be used by different software. So newer js version never replaces the old ones.
I would have expected 'js' to be removed when `js17` was updated and then 'js17' to be removed when `js185` became available?
And in this particular case, js17>js185, because js185 is 1.8.5 while js17 is 17.0.
So is this just one of those circumstances where you have to manually check if packages are no longer needed by the system and uninstall manually? It's not a big deal, but more a curiosity to understand when this type thing can occur in the normal process of just calling pacman -Syu.
Yes, this is the standard case of old dependencies becoming unneeded, it just seems strange to you because all those packages are js*, but if they have a different name and don’t upgrade over the previous one that’s for a good reason. Regards, Bruno
On 05/18/2019 04:45 AM, Bruno Pagani wrote:
Yes, this is the standard case of old dependencies becoming unneeded, it just seems strange to you because all those packages are js*, but if they have a different name and don’t upgrade over the previous one that’s for a good reason.
Thank you Bruno, That's all I needed to know. I just couldn't immediately see what that 'provides()', 'conflicts()' or 'replaces()' PKGBUILD contents would have needed to be to prevent it. The answer of "it shouldn't" because they are not direct upgrades makes sense now. -- David C. Rankin, J.D.,P.E.
Hi David,
Is this normal that new versions of packages are just added without removing the replaced package?
Yes, I think so. Checking for orphans is part of the normal process. https://wiki.archlinux.org/index.php/System_maintenance#Check_for_orphans_an... -- Cheers, Ralph.
On 17-05-19 18:23:00 -0500, David C. Rankin wrote:
Further checking whether any of the old packages are required shows they are not, e.g.
$ pacman -Qdt ... js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 ...
So is this just one of those circumstances where you have to manually check if packages are no longer needed by the system and uninstall manually? It's not a big deal, but more a curiosity to understand when this type thing can occur in the normal process of just calling pacman -Syu. Yes, pacman doesn't autoremove packages. It can be frustrating at times when a package can be removed due to a not so direct replacement. Here js52 does not replace js17 so I don't see how it can be removed.
-- Regards Jagan PUBKEY: https://j605.tk/pgp
On 18-05-2019 01:23, David C. Rankin wrote:
So is this just one of those circumstances where you have to manually check if packages are no longer needed by the system and uninstall manually? It's not a big deal, but more a curiosity to understand when this type thing can occur in the normal process of just calling pacman -Syu.
It's just a coincidence you noticed it when doing pacman -Syu. Running pacman -Qm and pacman -Qdt regularly should be part of normal system maintenance. LW
Am 18.05.2019 01:23, schrieb David C. Rankin:
$ pmq | grep '^js' js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 js60 60.6.3-1
What puzzles me is the wide range of version numbers with the un-suffixd package not even being the highest. Can anyone explain their versioning scheme, like does it make sense when read backwards or what? grateful for any sane explanation Georg
Le 20/05/2019 à 11:42, Georg a écrit :
Am 18.05.2019 01:23, schrieb David C. Rankin:
$ pmq | grep '^js' js 24.2.0-4 js17 17.0.0-4 js52 52.9.0-2 js60 60.6.3-1
What puzzles me is the wide range of version numbers with the un-suffixd package not even being the highest. Can anyone explain their versioning scheme, like does it make sense when read backwards or what?
The unsuffixed package being an old version is a legacy leftover. Note that we don’t have anymore a `js` package in the repo. The versioning scheme is actually quite simple when you know what this is about: js is Mozilla js engine from Firefox. js releases follow Firefox ESR ones, which were every 7 versions before (starting from 10) and 8 now. Next version will be js68, planned to be released early July. Regards, Bruno
participants (6)
-
Bruno Pagani
-
David C. Rankin
-
Georg
-
Jagannathan Tiruvallur Eachambadi
-
Lone_Wolf
-
Ralph Corderoy