I recently upgraded from Slack 9.1 to 10.0, and came up with a few questions after watching the mass upgradepkg process.

1. If files were changed in a directory in a particular package that was already installed, what does upgradepkg do if that same directory needs to be updated/removed in a newer 10.0 package?

For example, say mypackage-9.1.tgz contained /packages/mypackage/foo/file, /packages/mypackage/foo/file2, and /packages/mypackage/foo/file3. I then add /packages/mypackage/foo/file4. If I then upgradepkg mypackage-10.0.tgz (a package that also contains various files in /packages/mypackage/foo), what will happen to file4? What if I changed file3 and mypackage-10.0.tgz also contains a file3?

I kept seeing the warning messages saying that files within a package had been added or changed, and I'm trying to figure out what this could have messed up.

2. What will upgradepkg do if software was installed either through make install without Slack's packaging tools or by checkinstall but with a name that doesn't exactly match the Slack format (I saw a warning about this in the checkinstall documentation)? I remember going through a long process that didn't involved checkinstall to installed TeTeX, and then saw the Slack 10.0 process installed it as well. I'm not sure where the original was located, but I'm trying to figure out if I have duplicates on my system or if the upgradepkg deleted some of the old files but left some as the destination for both was probably the same.

I apologize if that was confusing to understand. Basically, I'd like to know if there's a way to figure out what might need to be fixed/changed because of the above situations.

If mypackage-10.0.tgz DOES NOT include /packages/mypackage/foo/file4, then /packages/mypackage/foo/file4 is left alone. If mypackage-10.0.tgz DOES include /packages/mypackage/foo/file4, then /packages/mypackage/foo/file4 is replaced with /packages/mypackage/foo/file4 from mypackage-10.0.tgz.

The pre-existing file3 will be replaced by the file3 from mypackage-10.0.tgz.

Note that this is all generically speaking. There is an exception to this if the files are configuration files. In that case, it is assumed that you do not wish to blow away your current configuration, so the original file is left in place and the new configuration file has a ".new" extension appended to it's name.

If a package was installed via "make install" it is not recognized by the Slackware package management system. "upgradepkg" alone will only give you an error. "upgradepkg --install-new" will install the new package, overwriting pre-existing files. It can have issues, though, in that it will not remove any files included in the older version that are no longer a part of the package being installed.

Basically, the same thing as above. You can simply "removepkg" the older package with the alternate name and you will be all set. No such luxury if you used only "make install."

Note that if you didn't install your self-compiled stuff with the same configure options that the Slackware packages use, you will most definately have orphaned files (or you could look at it as having two versions of the same software installed concurrently). If this is the case, "which" will be your friend.

All you need to know that upgradepkg (or installpkg) overwrites an existing file IF it also exists in the package being upgraded (or installed). A directory is deleted by upgradepkg or removepkg ONLY IF it is really empty (it contains no file) AND IF it is not referenced in another installed package. A file is removed by removepkg even if it has been modified, but a warning is displayed : see the removepkg(8) man page for the -warn parameter to generate a report instead of really removing the files and directories of the soon-to-be-removed package.

-- LiNuCe

Ok, I guess problems will come up eventually if they exist. One other question. How does Slack's package system know which files are configuration files that should be treated differently than ordinary ones. Is that something set when making the package or does it look for certain extensions? What about files that don't end in .conf like many in /etc?

Look in the a/etc package for Slackware Linux 10.1 : it installs a lot of /etc/*.new configuration files and its install/doinst.sh post-installation script takes care of renaming them properly (by removing the .new extension) if this is necessary (when the "old" configuration file has not been customized). Almost all Slackware's official packages use the same method to install new configuration files in a safe way.

-- LiNuCe

Ah, interesting. Thanks for the info.