SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
@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
Last edited by Didier Spaier; 01-21-2016 at 03:22 AM.
Reason: s/you system/your system/
@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.
..and using sbbdep this info is, not by accident, in a sqlite database just a not even very advanced sql query away.
Quote:
Originally Posted by Didier Spaier
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...
yes, afer removing something, it might be not there in future.
Quote:
Originally Posted by Didier Spaier
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.
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.
Quote:
Originally Posted by Didier Spaier
To shorten a long story, better let quietly sleep in you system shared libraries that maybe you will never use. As long as they do not snore, of course
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?
Code:
slpkg update
slpkg -upgradepkg *
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.
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).
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.
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?
However, apparently spi does not remove dependencies while removing packages, so it will leave orphan packages behind.
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.
Last edited by Didier Spaier; 01-22-2016 at 07:09 AM.
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.
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 also will be very useful for me.
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 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?
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:
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.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.