How exactly one manages the lack of dependency resolution?
 

I'm a longish time Debian user, considering giving Slackware a try.

One thing I don't quite understand is exactly how one goes by without having dependency resolution, or maybe I do.

What I'm hoping it is, is that it's more or less like what I have to do when I every once in a while install an out-of-date or the newer version of a package that isn't in the release I'm using, or yet, when I compile something -- I'll try to install, but either the package installer or the "config" part will tell me I don't have all the dependencies. Sometimes, I think I recall it happens in GIMP, but may happen somewhere else too, the config script will end with a listing of several optional things, and whether they're satisfied or not. From that listing I can infer what else I need to install, even if there's no exact package name correspondence (that helps a lot, though).

In the worst case scenario, I'd just better read the "readme" or something first, and there will be somewhere a list of dependencies, which obviously I'd install first, hopefully the "dependency tree" won't be extremely complex, giving me trouble to figure the sequence I have to install everything to avoid stumbling on many other failed installs of the dependencies due to unsatisfied dependencies of theirs too.


Is just that, or there's more to it?

hi the_dsc,

our user ruario wrote an article on the Slackware Documentation Project about this matter that will surely be enlightning for you

http://docs.slackware.com/slackware:..._off_slackware

I can't really improve on the ruario article that ponce linked to, but I haven't found it to be an issue dealing with dependencies in Slackware. Most lib files you need are included with the installation, and any others are easy to figure out, especially if you use SlackBuilds.

I was a Debian user for years, and actually gave it up over dependency resolution. Wouldn't go back to Debian if you paid me. Well, maybe if you paid me a VERY LARGE SUM. ;)

Dependencies are usually not a problems IF
you do a full slackware install
and/or
you use slackbuilds
and/or
slackpkg +
and/or
you use alien bobs scripts
and/or
... etc...

Don't misunderstand my comment, I love Slackware, ever since 1996 :) but there are sooo many ways to install software in this distro that it can be a little daunting, and yes read read read rtfm ... still doesn't make the number of methods to use to get a successful install any less. It is soooo cool to see so many innovated ways but when a new user is trying to figure it out it can be daunting... or when an old user comes back to start using Slackware again... I had kind of hoped there would have been a solid refined way by now...

gimp is a pretty exceptional example; building a newer version of gimp than what your distro includes is difficult on any distro, AFAIK.

You start with a full install for your stock Slackware installation (so you have no dependency issues to start with).

Third party packages that you get from Alien Bob don't have dependencies. He's been extremely good about building them that way.

The repository of packaging scripts, SlackBuilds.org, actually does have dependency information. There's a frontend for it called SboPkg, which includes a tool called sqg. You run sqg -a to generate package queues (lists of packages to install in order), then use sbopkg to install the entire queue. After generating the queues, sbopkg -i ffmpeg -k will install ffmpeg and all of its dependencies, skipping the ones you already have.

You'll start to appreciate it when you can just build and upgrade to a newer version of a package any time you want without dependency information getting in the way. Upgrading to a custom-built, newer, subpixel-patched version of FreeType won't hurt anything, won't block updates, won't require you to use apt-pinning, etc.

I second ruario's article.

And I would say that you need to rethink this part...

That should be the first case scenario - the place to start.

But as said by others, just do a full Slackware install and you will find uninstalled dependencies to be a non-issue in the majority of cases.

And my own attitude is that Slackware's package tools and method of dependency managment is one of its outstanding features - not a "lack" of anything!

Well ready made solutions are good for people's who like Microsoft Windows or Mac.

The scenario of Linux distros is changing to be like one of them. Particularly some gurus of this forum also lean, sleep that way.

And there are peoples who like to follow LFS and then BLFS so that they get total control atleast of packages installed in a system. And that needs experience as well as lot to be kept in mind of various package dependencies. It also needs lots of knowledge in different types of packages to be build.

And I am one of latter groups. You can indeed say that they are not package users but instead distro makers.

But if you enjoy manipulating the computer from software down to may be hardware you would enjoy such interests building from source and then relishing the finished product.

If you do so, all the complaints of packaging nightmares go off.

Sometime back I used these rpm, dpkg systems. But sometimes they just don't allow you to work peacefully and in a sane manner.

The only thing i can add to that great article is.... when i have to build something, and can't find a good slackbuild handy for it, linux from scratch (add lfs to your google search terms), Arch and gentoo write-ups are my best friends, usually in that order.

LFS - If it has an entry for it, that is generally all I need

Arch - usually has a wiki for it that really helps when there isn't an LFS entry

Gentoo - usually the first to have patches when things go wrong.

While I run slackware, linux as a community is a great place to work with.

There is an important difference. Debian has to cut up a single product into a thousand packages. Consider apache. Debian has apache, apache-dev, apache-mpm-event, apache-foo, etc, etc. You cannot install apache-lua unless you have lua installed.

Slackware has one apache httpd package. Its got everything (Except lua, which I've complained about). But pretend it did have lua, but you didnt have package lua installed. httpd wouldn't start, and it would complain that it cannot find lua.so.2 (or whatever). Oh, so, slackpkg install lua. Done.

I think dependencies suck. I tried out Ubuntu a while back, and the first thing I did was try to uninstall pilot-link. Cuz I dont have a palm pilot. But, no, uninstalling that uninstalls a thousand other packages, including your desktop. Stupid dependencies. I tried CentOS, really old perl. Never never uninstall perl rpm. You'll never get your system fixed again. Its bad. Trust me.

Its just not a thing. Or, its just not hard. Debian should not be proud that it has 42 million packages. No wonder it needs a database, and a searchable website, and dependencies. Its complicated.

Welcome to Slackware. Its different. Its simple.

As a primarily Micro$oft developer/architect/etc... developing applications or designing those to come with ready made scripts also require that I test for dependencies that the application requires and build into the installation script a method to analyze the users computer to see if they have the required components and if not to retrieve the missing dependencies and install them so that the application can be installed. Doing this keeps most if not all non-developer type users from having to do dependency checking and updating. All the user has to is run the installation and off it goes... unless there are options that the user wants to change. I dont see that this is wrong.

In order for to bring Linux to more users it would help if install scripts/process could do the same sort of thing. Linux wasn't supposed to be relegated to only the adventurous computer savvy as a toy. It would be nice to see more use as Linux is a more stable OS. Especially Slackware. Can't argue against an OS that can stand running for over a year and not need a reboot! However not everyone wants to be a computer guru or an OS guru... they want to access the web, they want to write documents, they want to do whatever it is they want that they need a computer to assist them with. My wife is a good example, she just wants to check her mail, do flyers, create newsletters for her womens group, etc...

And yes some rpm, dpkg systems can give a headache or be a nightmare... is that something to be proud of? or even perpetuate? Im a little aggravated on this topic because of trying to get a couple of things installed. I used to just build/compile and install. I even enjoyed that. Now I have to hunt the right repo, make sure I have some plugin... blahhhhhhh. I end up going back to doing (probably) the long way. A good example is Enlightenment. I have e17 on one laptop and e18 on a VM. Both I built/compiled and installed... and i didnt mind. However a friend of mine who isnt computer savvy would not be able to do this quite so easy given all the dependencies of Enlightenment.

I admit its hard to please everybody. At least with the members of this forum, Slackware is a bit more open to the general public and accessable for information. :)

Ahh. Ok, I have to admit I just installed octave, and it had a few dependencies, and took a little work to get compiled and installed. So, maybe is not all roses and butterflies.

Usually there is only one of two dependencies and it's not that bad.. Sometimes it can be a pain when the list gets longer and longer. sbopkg is really handy allowing you to create a build queue. There is even a project to provide complete queue files for packages on slackbuilds.org. Just find the queue file for octave and load it into sbopkg.

It's not too much of a problem unless there are lots of dependencies (think GNOME and Ogre). I usually know the dependencies of the programs I use, they are either listed or will be listed when './configure' fails. So you just go download that, run './configure', more deps, get those, './configure', then you install them as they compile (backwards). You probably want to Slacktrack or equivalent so as to be able to uninstall them.

Octave is one, and I build my own ffmpeg and vlc - vlc has the most for myself I think.

But walking through the SBo READMEs and REQUIRES tree to each leaf node is simple enough for me - no complaints! In the odd case where I need some different build options I sort those from the relevant READMEs and ./configure options as well.

I think the only case where people have trouble with it is when their package install expectations are all from a click-and-run-from-repo distro and they neither care nor want to think about what is actually happening to their system. In those cases, perhaps they should stay with the click-and-hope-it-runs distros.

As someone who's now used to manual resolution of dependencies, this is what I can say about it.

You kinda just have to do it. There is no magic to-do about manual resolution. It's about reading your package documentation, running configure scripts and having them fail, seeing what is not found and searching the web for it, installing dependencies and their dependencies as you come across them, and taking note of any features found in configure's help output.

Unless you have Slackware-sbo which has a good list of required and optional dependencies, or read BLFS and study their list of required, recommended, and optional dependencies and resolve as needed, its just something you learn to deal with due to the fact that not all dependencies will automatically be resolved. From time to time, even back when I used brand name distributions like Ubuntu, Fedora, and SuSE, there were times that a dependency wasn't in the repository, and guess who had to learn by doing?