hi@all,

what upgradepkg basically does is:

1. (pre)install the new pkg
2. remove the old pkg
3. reinstall the new pkg

somehow i forgot why upgragepkg is doing step 3, the script is telling me it has something to do with files changing location.

any help is appreciated, an example would be nice where leaving out step 3 will cause trouble.

Why do you care what it does? I assume that there were cases in the past where doing just the first two steps resulted in a broken installation.

EDIT: Looking through /sbin/upgradepkg itself, you can read about the --no-paranoia option and the comments related to it.

It seems that if a package used to directly manage a file and then someone changes the package to move the file into place, the install-new/delete-old method will result in the moved file disappearing. So, it's install-new/remove-old/install-new to ensure such files (normally configuration files) are correctly installed.

thx a lot for your help. i read the source but i didn't understand, but now i think i do.

example: an installed pkg has a file etc/c.conf in its file list. the new version uses the config() routine in doinst.sh to create this file. when removing the old pkg, etc/c.conf will be removed, because it's not part of the filelist of the new package.

is that correct?

1 members found this post helpful.

Yep. I think that's about right.

Whilst looking at some pkgtools changes for 14.2 and reviewing the speedup patches that ARM has, I came across this note I'd saved years ago when I asked Pat the same question:

ftp://ftp.arm.slackware.com/slackwar...tools/INFO.txt

There's your answer.

5 members found this post helpful.

thanks for sharing, so i can be sure my assumption are right. btw, it's another great example of how bad and harmful symlinks are (plan 9 has no symlinks for good reasons). you better avoid them like the plaque.

rob pike's comment on symlinks:
p.s.: are there important pkgtool changes in 14.2?

I like symlinks and use them extensively.

I think much of these problems can be laid at the feet of the utilities themselves. cpio seems to handle symlinks far more sensibly than tar does. It's a shame it's not been updated to support the POSIX.1-2001 archive format and has fallen out of use due to the limitations of 'ustar'. There is 'pax' from the heirloom toolset of course, but as that tends not to be commonly installed, its probably not wise to become dependent upon it.

Having said that, directories turning into symlinks and vice versa from one release to another is a complex situation, and it's probably not fair to lay the responsibility of dealing with it on an underlying archive tool. The package management tools themselves should deal with that sort of stuff. Installing the package twice seems like a quick and dirty workaround for the situation, but I guess it works.

now i remember another question i forgot to ask in the first place: why bother preinstalling a pkg? just to make sure the package will install without problems? i doubt that, because installpkg will happily install (at least it tries) a package onto my readonly /usr partition without complaining.

1 members found this post helpful.

Without the first install, if you were to upgradepkg tar, coreutils, sed, grep, or such packages, the remove will remove those tools, and (what is the second) install would fail due to missing programs. With the first install those tools won't be removed, since they are found in more than the package that is removed.

Patrick says:-