I noticed recently the change for --no-overwrite in installpkg and that got me thinking about something that has been on my mind for a while.

When I am doing machine upgrades (more common now with -current), then I am noticing a lot the time spent verifying/decompressing.

The change for no-overwrite got me looking at the installpkg/upgradepkg code, and I noticed that the current flow I believe includes 2 verifications (effectively, due to the two calls to installpkg if I'm not mistaken).

With the introduction of --no-overwrite, would it also be possible/appropriate to remove the verification from the second installpkg pass aswell?

Andypoo.

Silly side question: Is there a repository somewhere for the pkgtools scripts, or is their primary existance in the -current source tree?

I'm happy to provide patches for consideration if appropriate.

Andypoo.

1 members found this post helpful.

The official source of pkgtools (and anything in Slackware) is the Slackware distro tree you can find anywhere online.
Since 31 May 2018 I maintain a git repository which tracks slackware-current so you can more easily see the changes: https://git.slackware.nl/current/log/source/a/pkgtools

1 members found this post helpful.

@Andyppoo: as an aside, a lot of time is spent (spent, not lost!) in removepkg verifying that a to be removed file be not shipped in another package, in which case it should be preserved.

Indeed bash is slow, and there is an unofficial binary utility named spkg that tries to mimic pkgtools behavior while being way faster. As an example "spkg -d" does the aforementioned check way faster

Originally written by Ondrej Jirman it is currently maintained by George Vlahavas (also the Salix maintainer), here: https://github.com/megous/spkg

As I have discussed with George, it would be very useful to bring to spkg a feature provided by upgradepkg, that is the pre-installation of the new package before removing the old one. This feature can avoid to break the system preventing to use an utility necessary for it to work (the /bin/sh symlink to /bin/bash is a well known example).

George agreed but is very busy now, and my knowledge of the C language is almost non-existent. Your help to do that would be much appreciated!

1 members found this post helpful.

Yes, definitely. I was not planning on touching this removepkg process at all. And I also understand why the installpkg double-install trick happens.

It was more the installpkg initial verification that I was referring to which basically confirms that decompress is successful (and is also used to get the uncompressed size of the package). And I did not want it removed, just to be avoided running twice in short succession :-)

Andypoo.

Slow enough that using /sbin/ash usually results in a noticeably faster script. PV made a conscious decision to move from ash to bash years ago and I rather doubt that the reasons for that change have gone away or even weakened.

I didn't suggest to replace usage of bash in pkgtools by another shell (which others have done long ago to no avail) and don't really care (although I try to avoid extensions beyond the POSIX specification in my own scripts), but rather speed of any shell vs a compiled program.

Bash is one of the most viable shells because it is popular and an often targeted shell, but if you ignore that it has serious drawbacks and bugs. However the main issue is that reporting these problems in my experience is pointless because the community is more willing to pick apart an example script for being badly written than discuss the serious issues in bash they reveal while the devs wish distros to fix their own trivial bugs downstream because they are unwilling to merge patches.

I didn't mean to imply that you did make such a suggestion.