LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 07-16-2013, 04:08 PM   #1
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Rep: Reputation: Disabled
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. :-)
 
Old 07-16-2013, 04:50 PM   #2
camorri
Senior Member
 
Registered: Nov 2002
Location: Somewhere inside 9.9 million sq. km. Canada
Distribution: Slackware 14.1
Posts: 4,851

Rep: Reputation: 432Reputation: 432Reputation: 432Reputation: 432Reputation: 432
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.
 
Old 07-16-2013, 05:00 PM   #3
thirdm
Member
 
Registered: May 2013
Location: Massachusetts
Distribution: Slackware,OpenBSD
Posts: 86

Rep: Reputation: Disabled
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.
 
Old 07-16-2013, 05:11 PM   #4
Didier Spaier
Senior Member
 
Registered: Nov 2008
Location: Paris, France
Distribution: Slackware{,64}-{14.1,current} on a Lenovo Thinkpad T61 6457-4XG
Posts: 4,381

Rep: Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088Reputation: 1088
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.

Last edited by Didier Spaier; 07-16-2013 at 11:13 PM. Reason: typo corrrected
 
Old 07-16-2013, 07:12 PM   #5
jtsn
Member
 
Registered: Sep 2011
Location: Europe
Distribution: Slackware
Posts: 806

Rep: Reputation: 362Reputation: 362Reputation: 362Reputation: 362
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.
 
1 members found this post helpful.
Old 07-16-2013, 09:06 PM   #6
BCarey
Senior Member
 
Registered: Oct 2005
Location: New Mexico
Distribution: Slackware
Posts: 1,475

Rep: Reputation: Disabled
Quote:
Originally Posted by jtsn View Post
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
 
Old 07-16-2013, 09:44 PM   #7
TobiSGD
Moderator
 
Registered: Dec 2009
Location: Hanover, Germany
Distribution: Main: Gentoo Others: What fits the task
Posts: 15,592
Blog Entries: 2

Rep: Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047Reputation: 4047
Quote:
Originally Posted by BCarey View Post
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.
 
1 members found this post helpful.
Old 07-16-2013, 10:00 PM   #8
tommcd
Senior Member
 
Registered: Jun 2006
Location: Philadelphia PA USA
Distribution: Lubuntu, Slackware
Posts: 2,230

Rep: Reputation: 287Reputation: 287Reputation: 287
Quote:
Originally Posted by Pearson View Post
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.
 
Old 07-16-2013, 11:22 PM   #9
lems
Member
 
Registered: May 2004
Posts: 144

Rep: Reputation: 44
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

Last edited by lems; 07-16-2013 at 11:25 PM. Reason: Added link
 
Old 07-17-2013, 05:17 AM   #10
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 477

Rep: Reputation: 122Reputation: 122
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.
 
1 members found this post helpful.
Old 07-17-2013, 06:02 AM   #11
mlslk31
Member
 
Registered: Mar 2013
Location: Florida, USA
Distribution: Slackware, FreeBSD
Posts: 117

Rep: Reputation: 40
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...
 
1 members found this post helpful.
Old 07-17-2013, 06:49 AM   #12
elesmod
Member
 
Registered: Sep 2012
Distribution: Slackware
Posts: 84

Rep: Reputation: Disabled
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
 
6 members found this post helpful.
Old 07-17-2013, 06:51 AM   #13
solarfields
Member
 
Registered: Feb 2006
Location: Outer Shpongolia
Distribution: Slackware
Posts: 477

Rep: Reputation: 122Reputation: 122
you lost me

 
Old 07-17-2013, 07:33 AM   #14
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by elesmod View Post
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.
 
Old 07-17-2013, 07:40 AM   #15
Pearson
LQ Newbie
 
Registered: Jul 2013
Posts: 9

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by solarfields View Post
you lost me

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.
 
1 members found this post helpful.
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] Sanity check LFS 7.0 - do I need to re-add packages in GCC pass 2? DrinkinHomeBrew Linux From Scratch 2 12-19-2011 10:23 AM
Installing/deinstalling packages under Ubuntu & handling boot problems with Grub ... rakeshj Linux - Software 2 07-15-2007 02:27 PM
Packages & Installing software Spamdrew Slackware 4 07-03-2006 10:36 AM
Updating custom packages - best practices dunric Slackware 1 01-10-2006 07:36 AM
best practices for subprocs & pipes in python bardinjw Programming 0 11-28-2005 12:27 PM


All times are GMT -5. The time now is 12:28 PM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration