Dependency Documentation? Is it just try-it-and-see?
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.
Dependency Documentation? Is it just try-it-and-see?
Hi, n00b here. I've run Gentoo for a couple of years, and have been running Arch for a year or 2. I previously tried Slackware however I didn't really get it.
I think I understand some of the reasons why its not great to automatically install every dependency that the packager thought might be useful when they packaged the app. (This is something which Gentoo takes care of with USE flags I guess).
Is there some documentation for packages around, showing what dependencies might be needed? Is this something which is part of the downloaded package file in a documentation file?
Is it something that should be got from the app writer's own website?
It seemed to me that Slackware's lack of automatic dependency resolution was a great theory but that in practice I'd end up with one of the helper apps such as slack-get, which puts automatic dependency resolution back in.
So, sorry if this is a stupid question and sorry if its been answered in 5000 other places. I was surprised that there wasn't something in the FAQ though.
1st rule is always run with a full installation of Slackware unless your really sure about what your doing with it
If you want to compile things from source you should check http://slackbuilds.org/ and if it is there it will also list the dependencies you need.
If your compiling from source but it's not on slackbuilds then when you run "make configure" or cmake on the source you will get the deps as an error message if anything is missing, you just then grab them and add to your system as needed.
You should also think about optional deps that are not required but may add extra functionality to the package your trying to add.
The dependencies are usually listed at the same place you got the package from.
If none are listed then there are probably no dependencies that aren't already included in the default Slackware installation.
This suggests using pkgtool and installpkg. From there I'm not sure where I'd see the dependencies?
Installing (or building it then installing it) and seeing what dependencies are flagged as missing is one approach, but that is required (rather than optional) dependencies. If there is no choice as to whether dependencies need to be installed then there seems little gain to having to install them manually, other than possibly giving a greater knowledge as to what is installed on your system, which may be no bad thing.
I guess its the optional dependencies that I am thinking about as well.
Typical approach in slackware is to install an application using installpkg, then run it, it throws an ugly error that means, some obscure library is missing. Then you figure out what program might provide that obscure library, install it and try again. This time there is different error message that some other obscure library is missing - you repeat the process of finding the right program, install it and try again. This time the initial program starts and works without issue - you've just resolved all dependencies.
More and more you do this kind of trial and error installation, the better you get at estimating what is missing.
The more advanced way is to install the program and then use ldd command to see, what libraries it requires. This way you don't have to run it to see the dependency resolution failure.
If you build packages yourself from the source you should find out about optional dependencies either from the developers website, the documentation that comes with the source or, if that package is in their database, from SlackBuilds.org.
Fantastic, thanks everyone. I was going to give Gentoo another go but I think I'll try Slack again.
Previously I'd looked at installpkg, had no idea on dependencies and had settled for slack-get. I'd then felt frustrated that this seemed like running Ubuntu with a more fashionable name, and so tried something else.
Typical approach in slackware is to install an application using installpkg, then run it, it throws an ugly error that means, some obscure library is missing. Then you figure out what program might provide that obscure library, install it and try again. This time there is different error message that some other obscure library is missing - you repeat the process of finding the right program, install it and try again. This time the initial program starts and works without issue - you've just resolved all dependencies.
More and more you do this kind of trial and error installation, the better you get at estimating what is missing.
The more advanced way is to install the program and then use ldd command to see, what libraries it requires. This way you don't have to run it to see the dependency resolution failure.
This is a fun thing to do when you have no information about the dependencies. Most of the time the dependencies are listed in the documentation.
Also, a full install of Slackware (the only recommended way to run it) has almost everything except the kitchen sink.
When you install from source, you can ultimately ask the person who wrote the code.
Long story short, automatic dependecy resolution can be nice, but you don't actually need it all that ofthen.
Lastly, most slackers could care less about the package management system, once the system is installed and configured, there is no need to go in and change things.
Edit: for add-on software, I can really recommend using slackbuild scripts. You can find them all around the internet, but my first stop always is slackbuilds.org. At slackbuilds.org, all dependencies that aren't in a full slackware install, are listed in the README.
This is a fun thing to do when you have no information about the dependencies. Most of the time the dependencies are listed in the documentation.
Also, a full install of Slackware (the only recommended way to run it) has almost everything except the kitchen sink.
When you install from source, you can ultimately ask the person who wrote the code.
Real [h,sl]ackers do not RTFM Als it is much more interesting to do minimal install and then start adding dependencies one by one and hoping that maybe in the end you get away with something less than full install.
If you build from source, then usually ./configure fails miserably if one cannot find dependency. Thats always amusing.
Use 'sbopkg' and its queue files, especially if installing something with a lot of dependencies, like ffmpg. For majority of apps with few dependencies this isn't even necessary if you have all stock libraries installed. Non-stock dependencies are listed in Readme files in Slackbuilds.org. If a program is not in the slackbuilds.org, dependencies are probably listed on programs web page or in INSTALL or README files in the source tarball.
For easy compiling of non-slackbuilds packages i suggest src2pkg, or ./configure && make && trackinstall routine, trackinstall is includedd in src2pkg.
Additionally, the only thing that's going to track what you've installed from source is you! I've been keeping a spreadsheet since I started using Slackware which lists everything I've installed on the system, their dependencies, which version, and where I downloaded them from. As for removing programs built from source, I do believe the majority of what I've seen has had an option for 'make uninstall', which is something I didn't notice until recently :P.
Oh!
As for sbopkg, make sure you log into root using 'su -'. The hyphen is important because some programs require certain root paths to compile and this brings you into more of a true root than plain 'ol 'su' (I hope I explained that correctly, someone correct me if I'm wrong.)
As for removing programs built from source, I do believe the majority of what I've seen has had an option for 'make uninstall', which is something I didn't notice until recently :P.
Or you use makepkg to make a package from the compiled binary, so that you can remove the software with removepkg/pkgtool/slackpkg.
ldd sounds interesting & tried ldd --help and man ldd as usual my computer didn't come out with too much info & if it could talk I would ask- can you elaborate!
the format seems to be " ldd file" its getting the context to "file" that i don't understand
do you use it with the launch command for a program?
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.