removepkg behavior
 

Hi, I'm trying to setup a small 12.2 server, with openssh, samba, sendmail, etc. I want a small system, with just the necessary tools to do the job (without X, java, ...)

I've installed all the programs in the a ap d l n and then after the first boot I've removed unnecessary packages with pkgtool.

The problem is that removepkg doesn't remove *all* files in a package, and seeing stales files on my system annoys me.

For example, I've removed hal -- but /etc/rc.d/rc.hald is still there. Why is that?

After a little debugging I have noticed that removepkg doesn't remove .new files -- what are those files? And how can I totally clean my system?

Here is the output of 'removepkg -warn hal | grep -i skipping':
Thank you.

The .new files are used to prevent overwriting the existing configuration files (which the user presumably has customized in some way and doesn't want to lose). When you upgrade a package, any configuration files under /etc will be preserved, and the updated configuration file will be placed in the filesystem with the .new extension so you can review it and see if you want to use it or not.

In the case that there is no configuration file currently, the install script will then simply remove the .new extension. The problem is, the file appears as .new inside of the package itself. When removepkg goes through all the files installed and tries to remove them, it won't recognize the renamed files since they weren't in the original package.

To be perfectly honest, I am not sure why it is done this way. Logically it seems to make more sense that the install script would add the .new extension if it sees existing configuration files, rather than remove the extension if it doesn't. That way it would be less likely a stale file got left behind (though if you didn't do anything with the .new, that would still remain).

Perhaps somebody else knows why this is, I would be interested in hearing the rationale.

Thanks MS3FGX, now I know what those files are.

I agree.

In the meanwhile I will have to remove the files by hand :(

you can use slackpkg for upgrading which will look for and help you to deal with the .new files as you install the packages. You can also look for these with `slackpkg new-config`.

The install script is run *after* the package is already de-compressed on your system, so it can't rename the files at that point. Most packages which install a conf file under /etc use a small routine (the config() function) which handles the installation and ovweriting of conf files. The files are inside the package with the *.new suffix. when you first install the package and there is no conf file without the .new suffix, the config routine renames the file to drop the .new suffix. If you don't make any changes to the conf file and there are no changes to the conf file in a later version of the package, when you upgrade the package the *.new file will be discarded. But, if you have made any changes to the file or the file in the newer package is not the same as the old one, then the file with the .new suffix will be preserved and not overwrite the existing file.
Since the files comes in the packages with the .new suffix, removepkg will only remove them if they still have that suffix. This means that the files with the suffix do not get removed by removepkg.

This is all just a simple mechanism to avoid that the installation or upgrade of packages overwrites config file which you may have edited. Imagine how mad you'd be if you had worked some super-duper custom configs for a ceratin package and then your conf file got overwritten when you upgraded the package.

Another thing is, that the etc-.x.x.-noarch package which is on your system contains quite a few generic conf files for packages which may or may not be installed on your system. These conf files are nearly always very smal anyway, so it's not like you are wasting a bunch of space. There is one quite large conf file whcih gets installed and is not used by default -the /etc/termcap-BSD file is 690K. You can safely remove that and you will save more space thatn by removing all the small leftover ones from packages you have removed.

If, as you say, you simply want to eliminate *all* files which are unused, then you have quite a bit to do there in /etc -but you'll need to investigate them thoroughly to make sure you know what each one is for and whether or not it is being used.

Thanks gnashley for a great answer. I can certainly live with the files laying around in /etc (which is about 10mb anyway), but it's just a little annoying :-)

Another "workaround" would be not to install the package in the first place, but that will make the installation a little more tedious.

And one more thing, I've always did a fresh install on every release, if I install my "minimal system" and if I upgrade to 13.0 in the future, can I just simple update the installed packages and do not install new packages? (with upgradepkg --install-new as noted in UPGRADE.TXT)

Not likely. Sometimes "new" packages are even just older ones that got renamed in their update. Also, you might actually want some of the newer packages.

That being said, you won't have to install all of the newer packages and then go back to removing the ones you don't want. You will just have to pay a lot more attention to your upgrade process than others upgrading a full install. As you might already know, upgrading Slackware is never just simply updating the installed packages (see the HowTos in my signature).

I see. I like Slackware too much to be upset about the update process and the files laying around in /etc, so I think I just have to live with it. One more question, if I install the a, ap, d, l, n series only, can I upgrade just that?

If you have the Slackware sources mirrored (try Eric's mirror-slackware-current.sh tool - it works for more than just -current and you can select which folders to mirror) you could do something similar to this:

I believe slackpkg will let you upgrade only by series as well. I have not tried this, however.