LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Best practices for mainlining sanity installing & removing packages? (http://www.linuxquestions.org/questions/slackware-14/best-practices-for-mainlining-sanity-installing-and-removing-packages-4175469854/)

Pearson 07-16-2013 05:08 PM

Best practices for mainlining sanity installing & removing packages?
 
I used Slackware for quite sometime years ago. I finally migrated away because I was wasting too much time worrying about package dependencies. After using a few different distros over the intervening years (latest was Arch, till my HD died) I'd like to go back to Slackware's KISS approach (but less bleeding edge than Arch).

From what I can read, it seems that using slapt-get or swaret are still officially frowned upon (while still being quite popular -- they were very new the last time I used Slackware).

I suspect my earlier frustration with package dependency was due to being disorganized. So, I'd like to know what kind of best practices are there to:
  1. Find the dependencies of a package before installing it, possibly recursively
  2. know what packages I can safely remove if I decide to remove a package (e.g. I wanted to try out something and had to install other things)

I like keeping "system bloat" to a minimum, which is why I'm asking about removing unneeded packages. I also like to occasionally try out new software.

I'll gladly follow the advice of RTFM, as long as it includes help finding the right place to read. :-)

camorri 07-16-2013 05:50 PM

For packages that are not part of the supplied system, I use SBOPKG. It has queue files, that allow you to install a package and all its dependencies. It doesn't do dependency checking, however, I have not found any problems with this approach. It uses packages from slackbuilds.

See this link -->http://www.sbopkg.org/

Sbopkg is not officially supported, however, a lot of slackers use it.

No comment on what you can remove. Disk space is not a problem for me, so I do a full install.

thirdm 07-16-2013 06:00 PM

Have you tried building everything you need that's not already in the main distro from source yet? It's too early for me to say whether it's a best practice or not but I'm finding this approach very good at "keeping system bloat to a minimum" though perhaps not so good at "wasting too much time worrying about package dependencies." The time consuming part helps keep down the bloat. Plus bloat can only be defined by you, so you'd best look at the source tree documentation and configure --help output to decide what you can leave out and how. For instance, I found myself able to leave out doxygen when I installed rtorrent and its dependencies (I think it was libsigc++ that needed this) by using configure flags. doxygen has some kind of annoying dependencies IIRC. I wonder if someone packaging libsigc++ would feel they could get away with leaving out the documentation, though.

Maybe a more efficient approach would be to get slackbuild scripts from the reliable sources and edit them if you feel they pull in, er enable, too much. But I'm not sure I like the level of indirection there. If you're going to do that, why not deal straight with the source itself? Seems to me there's a contradiction between the wish to keep your system free from cruft and running someone else's build script that will automatically install things in ways you don't completely understand unless you read it over first (at that point, you could have read the original source, yes?). Well, unless you really trust the person who made it to share your taste re what's bloat.

One thing I noticed, perhaps not so good, is that if you use mostly default configure flags from vanilla upstream sources they tend not to stick libraries in lib64. I think I won't be running 32 bit programs so I kind of don't care if there's an arbitrary split of 64 bit libraries between /usr/local/lib and /usr/local/lib64, unless it causes headaches later. Seems a shame, though, that the FHS didn't make it lib32 and have the 64 bit stuff go in plain lib. Could be worse, they could have done like windows and put 32 bit binaries in directories with the number 64 in them, wow.

Didier Spaier 07-16-2013 06:11 PM

Hi and welcome to LQ.

If you don't want to worry about dependencies, just make a full install. I realize that's not the answer you expected, but I have yet to find any practical inconvenience of what you call "system bloat", provided you have enough space on disk.

If you installed a program but don't use it, it won't slow down your system, not will it put it at risk.

If you want to try a new software (not included in Slackware) you'll have to look for information about dependencies in the source package itself, or in its website.

If you build the package yourself using a SlackBuild provided by http://slackuilds.org, you will find dependencies (not recursive ones, though) listed in the README file. Bear in mind that a full Slackware installation is assumed in that case, in other words dependencies part of Slackware are not listed in the READMEs.

But to ease building and installing packages using these Slackbuilds, you can rely on sbopkg and its queues files, that somehow can automate the process.

Keep a note of third party packages you install as dependencies of other packages, thats IMO the best way to know what you can safely remove.

jtsn 07-16-2013 08:12 PM

For Slackware itself use a full install. You can leave out some packages series, you don't like to use (like e, kde, kdei, t, xfce).

For third party packages I recommend self-contained packages with dependencies included like http://connie.slackware.com/~alien/slackbuilds/vlc/

Slackware pkgtools can also track files owned by multiple packages and automatically remove them, if the last package gets uninstalled.

If you like the more fine-grained approach http://download.salixos.org/ has a big repository of prebuilt packages available including dependency-resolving. Just as usual with these solutions, from time to time stuff breaks and you have to deal with it.

Building packages from source using http://slackbuilds.org is also a great option, but you then almost become your own distribution maintainer. You have to work out on your own, what packages you build, how you they work together and how you upgrade them. The are tools like http://sbopkg.org which can semi-automate syncing and downloading, but that is in no way a fully-automated system like portage. I usually take the slackbuilds out of the tree, make my own customizations and then build my packages. Keeping track of how stuff is linked up and what breaks what is essential.

And last but not least, you can also download ready-to-use applications bundles like http://www.mozilla.org/en-US/firefox/all/ or games from the http://www.humblebundle.com/, extract them into your home directory (or into /opt) and just run them from there. There is no requirement to install everything into /usr and registering it with pkgtools. http://store.steampowered.com/browse/linux/ works the same way.

BCarey 07-16-2013 10:06 PM

Quote:

Originally Posted by jtsn (Post 4991590)
Slackware pkgtools can also track files owned by multiple packages and automatically remove them, if the last package gets uninstalled.

AFAIK pkgtools does not track anything or do anything automatically. Can you elaborate on what you mean?

Brian

TobiSGD 07-16-2013 10:44 PM

Quote:

Originally Posted by BCarey (Post 4991639)
AFAIK pkgtools does not track anything or do anything automatically. Can you elaborate on what you mean?

Brian

If more than one package contains a specific file removepkg by default will not delete that file if you remove one of the packages, but will remove it once you remove the last package that contains that specific file.

tommcd 07-16-2013 11:00 PM

Quote:

Originally Posted by Pearson (Post 4991514)
From what I can read, it seems that using slapt-get or swaret are still officially frowned upon (while still being quite popular -- they were very new the last time I used Slackware). ...

If you would like Slackware with dependency management, you may want to consider Salix: http://www.salixos.org/wiki/index.php/Home
Salix is essentially Slackware for desktop users that automatically boots to a graphical logon, and uses slapt-get (and gslapt if you want a GUI) for package management.
Salix packages can also be installed on Slackware without fear, as jtsn stated.

I have used Salix off and on since it was first released and it has always worked well in my experience. The Salix developers are hard core Slackers who know what they are doing.

lems 07-17-2013 12:22 AM

You could also try pkgsrc (with pkgsrc-wip) if you don't mind compiling stuff.

Edit: There also was an (older) article on running pkgsrc on Slackware: http://web.archive.org/web/200702020...slackware.html

solarfields 07-17-2013 06:17 AM

Pearson,

If you install your third party software from http://slackbuilds.org/ you can use sbotools to automate the installation process from there. You can install it from SBo. Another approach, as camorri mentioned above is to use sbopkg in combination with build queues. There is a script called sqg that can generate a build queue automatically for any entry from SBo (as long as it is the 14.0 repository) or can generate build queues for everything in the repo.

Now, generating a single queue file, for example for QtiPlot is as simple as:

sqg -p QtiPlot

While generating all queue files is done by:

sqg -a

After that you can easily navigate and load the queues you need in sbopkg.

Hope this helps.

mlslk31 07-17-2013 07:02 AM

I use a simple system like this:

Code:

$ find {,/usr,/usr/local}/{bin,sbin,lib,libexec} -mount -type f \
 -executable -print -exec ldd -v {} \; | tee ~/exe-deps

$ grep "not found" ~/exe-deps | sort | uniq -c | sort -g

# for manual searches

$ less ~/exe-deps

This way lets me know rather quickly if I've deleted one library too many. Pat's done a good job with slackware-current with regard to keeping bloat out of the non-X11 sections. For my setup (no KDE), it's the n/ and l/ disk series that are adjusted most often by using this method.

Once another stable Slackware is released, I'll compile it around in circles until there's no junk left. It's not quite the magic bullet that it used to be, though, and the larger C++ projects are a strain on old hardware. It helps to use gold for these projects.

BTW, I've known some people that have tried "mainlining sanity." It doesn't work. Maybe if they had used "apt-get heroin-fix", it would have worked a little better...at least the doses would have been correct...

elesmod 07-17-2013 07:49 AM

You could manually log the packages and their dependencies that you install using sbopkg.

Let's say I'm installing a program from slackbuilds.org named "oranges", in the info file there are listed dependencies: "bananas" and "grapes". Upon checking the info files of the 2 dependencies, I find that "grapes" also needs "libwatermelons" :)

So, into my "installed_packages.txt" I type:
Code:

oranges: bananas grapes
grapes: libwatermelons

If I later install a program "tomatoes" (yes, they're fruits too) that also requires "libwatermelons", my file would look like this:
Code:

oranges: bananas grapes
grapes: libwatermelons
tomatoes: libwatermelons

After a year, I decide to remove the "oranges" program and it's dependencies. So I:
Code:

$ grep oranges installed_packages.txt
oranges: bananas grapes

I can see that "oranges" is not anything's dependency, so I remove it. But I see 2 deps, so I grep them next:
Code:

$ grep -E "bananas|grapes" installed_packages.txt
oranges: bananas grapes
grapes: libwatermelons

I can safely remove "bananas" and "grapes" since they were only deps of "oranges". But I have to grep again for "libwatermelons"
Code:

$ grep libwatermelons installed_packages.txt
grapes: libwatermelons
tomatoes: libwatermelons

"libwatermelons" is also a dependency of "tomatoes", so it needs to stay installed :)

Yes, it's kind of troublesome, but maybe this will give you some other ideas on how to manage your stuff :)

solarfields 07-17-2013 07:51 AM

you lost me

:scratch:

Pearson 07-17-2013 08:33 AM

Quote:

Originally Posted by elesmod (Post 4991867)
You could manually log the packages and their dependencies that you install using sbopkg.
[...]

Yes, it's kind of troublesome, but maybe this will give you some other ideas on how to manage your stuff :)

I was thinking the solution would be something like this. I guess sbopkg doesn't have useful logging features?

For simplicity, would it make sense to copy the info file for all packages I install (via sbopkg)? Then I could grep those info files, and there's less copy/paste (chance for error!) involved.

Pearson 07-17-2013 08:40 AM

Quote:

Originally Posted by solarfields (Post 4991868)
you lost me

:scratch:

If you're referring to the fruit example, he's basically building a database in a text file of dependencies. If you're familiar with SQL, think of it like this:
It's a table with two columns: package (key) and dependencies
The INSERT is done manually with a text editor
The SELECT is done with grep
The DELETE is done manually with a text editor

So, every package that is installed is also INSERTed into the database. Before removing a package, SELECT the package name from the database. If it's only in the key column, nothing depends on it and it can safely be removed. If it's in the dependencies column, then he has to decide whether to remove the package that depends on it. Wash, rinse, repeat.


All times are GMT -5. The time now is 09:22 PM.