@Hosein: to be picky a library can be a dependency of executable programs aka binaries, not of packages.

So, to check that, one would have to run ldd, readelf, whatever against all executable programs, to make a list of all shared libraries found this way, then check all installed shared libraries to see if they are in that list and else consider removing them.

But a shared library can be installed "just in case", so additionally one would have to check that those in the list were not shipped in a Slackware package, and if that is the case also check if by chance all the other shared libraries possibly shipped in the same package are not used either, then and only then maybe decide that you can safely remove that package.. Just to realize that you will need to reinstall it as a dependency of another package that you want to install one day later...

That's to be able to do such things that other distributions use tools to automatically (when all goes well) manage dependencies, and also cut the packages in thin slices to ease the process, at the expense of more work for the maintainers.

To shorten a long story, better let quietly sleep in your system shared libraries that maybe you will never use. As long as they do not snore, of course

2 members found this post helpful.

That sounds like a good idea. So neither slpkg nor usm do anything that may be said to be similar to removing orphan packages in other systems.

..and using sbbdep this info is, not by accident, in a sqlite database just a not even very advanced sql query away.


yes, afer removing something, it might be not there in future.


oh yes, when I recently made my first steps and build a package with obs, the dependency thing is ...pfffff, made me tired, the list is longer than the rest of the build script.
on the other hand, so spec files are often a very good source to find out stuff if you want to build something, big thanks to the people doing this job.

no, lets play with your system as you wish, but do not cry if something is broken, take it as a positive that you learned something

Which command is used to upgrade all the packages? Will following commands do it?
Will these also upgrade packages installed through original installation and not through slpkg (slack repo is enabled in slpkg)?

No, you must use "slpkg -c <repositoryname> --upgrade" for upgrading installed package from specific repository. For instance for upgrading genuine slackware packages you must use: slpkg -c slack --upgarde

This command upgrade all upgradable packages from slackware repository not only those which installed by slpkg itself.

Yes, by default slack repository has been selected in repositroies.conf file.

Thanks for explaining.

I tried slpkg on a Salix installation. I had earlier installed vlc on that distribution and at that time a number of dependencies were installed (by gslapt). Now when I tried to remove vlc with command 'slpkg -r vlc --deps --checklist' it showed only vlc to be removed. I removed vlc. On trying to re-install vlc with slpkg using command 'slpkg -s salix vlc' it gave message that many dependencies need to be installed as well. Hence, 2 errors occurred: 1. slpkg did not list dependencies to be removed alongwith vlc. 2. While installing, slpkg tried install the dependencies even though they are already present on the system. I hope my commands were correct.

Should be avoided in general the installation of large packages of Salix repository.
Vlc package is adapted to distribute Salix and if you try to remove perhaps remove packages Slackware default packages (like cairo package).

I prefer install vlc from alien repository.

Is there a link discussing how slpkg detects dependencies while removing packages- those installed by slpkg itself and those installed by original system?

When install packages with dependencies with command "slpkg -s <repository> <package...>" then text file create with package name and dependencies in "/var/log/slpkg/dep" directory".
When try remove package, slpkg read text file from "/var/log/slpkg/dep" directory.

You can recognize packages by "tag".

@rng

Just for curiosity, Why don't you use spi for salix? using slpkg on slaix is a bit tricky as you must use modified sbo which is provided for salix instead main sbo repository.

Thanks for pointing out an important issue regarding sbo packages for Salix. I have used spi and found it to be good. However, apparently spi does not remove dependencies while removing packages, so it will leave orphan packages behind. This removal of dependencies seems possible with slpkg in most situations.

I also want to bring up another issue regarding slpkg. With some repositories (like ktown and rlw), both 32bit and 64bit packages are picked up and are selected to be installed with commands 'slpkg -F pkgname' or 'slpkg -s ktown pkgname'. Why is slackware not selecting appropriate architecture from these repositories and how can this be corrected?

What do you mean by "orphan package"?

Let's assume that you installed a package A as dependency of a package B and also a package C that has A as dependency too.

Now you want to remove B. If you also remove A as a dependency of B, C won't work anymore, assuming that A includes a run-time dependency of a binary shipped in C.

Of course you or the tool you use can check that there be no other installed packages having A as dependency, but that complicate things, uselessly in my opinion: keeping A even if no more used won't hurt, but in specific situations like a hosted system for which the fare depends on the amount of storage used, or a very small root partition. But I doubt that be your situation.

More generally I fail to see the need to remove any installed package, again but in a specific situation.

PS To avoid a possible misunderstanding I am not saying that effort by tools developers to include such features are futile, just that they should be used only when really needed and with some caution.

In my case, the space is important since I want to install Slackware with Mate desktop on a usb pendrive. I find that even if I install XFCE and not KDE during installation, many KDE packages are still installed. So a package manager which removes dependencies will be very useful for this.

KDE is a whole series (kde) that can be disselected during installation,
you might also want to look at the mini slack from MELD, which is a minimal Slackware, or MELD itself might also be intresting even if you want Mate insteat of XFCE.
Salix Mate might also be an option,

I am not familiar with rlw and ktown repositories as I didn't use them yet. Maybe this issue originates from installing slpkg on Salix. I guess modification of "/etc/slpkg/default-repositories" and correcting the urls of these repositories will solve the problem. For, instance for ktown repository on 64bit system modify ktown url like this:

http://alien.slackbook.org/ktown/14.1/latest/x86_64/

and then run "slpkg update"

However, if I be you I didn't use alien and other Slackware-oriented repositories on Salix as all of them assume full installation of Slackware and surely you will experience some dependency related problems.

1 members found this post helpful.