Dependency resolving often has limitations as well.

Most distributions that do this often have multiple packages for different components like a binary package and a developers package, some even have documentation separate as well. This means a lot more to manage, a lot more to install, troubleshoot, debug, etc.

By not using automated dependency resolving and leaving it up to the user/administrator to self-manage you can install more, manage less, worry about less, and create better customizations for the system.

If you need help with dependencies, check SlackBuilds to see what all packages are often needed for packages you install and use outside the main packages. In a way this teaches you more and allows you a better learning curve to become more accustomed to how Linux and the GNU OS works as a whole.

All posts of this nature should be reported and locked as the advantages and disadvantages have been fully discussed. No new information can come of this with regards to slackware that can't be found with a quick google search.

Either way, my take is that because it's a complete system, most of the dependencies are there for most programs to be compiled (aside frome things that run on gnome libs) This is no different than any other OS as you are ultimatly going to be forced to use some 3rd party repository or compile your own packages for things like libdvdcss. At least with slackware's most popular 3rd party repositories, you know exactly what you need to make it work and you know that some rogue package isn't going to require a needless upgrade to QT, Gcc, GTK, Python, or anything else that nobody should ever upgrade without serious thought to the consequences (aside from upgrading the distribution version completly)

Yeah! I feel like I contributed my 2 cents along with everybody else. Woop.

1 members found this post helpful.

Been down this road, and asked the same question so may times and always get the same answer. The only reasonable conclusion I can come to (in my mind anyway) is that the only true way to get proper dependency resolution, regardless if distro, is to have every program you are ever likely to need packaged with all of its dependencies, and installed into its own directory, leading potentially to massive duplication of everything.
Or, do it the Slackware way, and become your own dependency

In my opinion, definitively specifying dependencies in some standardized fashion should be the responsibility of the upstream developer. From that, each distribution could then assemble packages WITH dependency information without putting undue burden on the maintainer. However, such a solution would never work.

1) Nobody would ever agree on a standard way to describe dependencies.
2) Even if we had a standard, developers are lazy and would fail to do it or keep it updated.
3) Even if they keep it update, they would want to do things in some hackery way that was incompatible with the standard. (Even if you write a standard that covers all corner cases, developers will invent new corner cases that aren't covered just to be difficult.)
4) You would still have the problem of projects that have non-standard version tagging or break best practices by changing the API in a minor revision.
5) You would still have the problem of handling alternatives (GNU vs Busybox, OpenOffice.org vs LibreOffice, imagemagick vs graphicmagick, Sun-Java vs OpenJava vs GCJ vs Apache Harmony vs ..., Vim vs Vile vs Elvis vs nvi vs Busybox-vi vs vi-ex).

There really already is one. The slack-required file.

No, I mean for the UPSTREAM DEVELOPER to specify their dependencies, not how the resulting Slackware packages should specify it.

Maybe the dependency on specific program/library/version etc is flawed in the first place. If there would dependencies of funtionality, then the whole picture would be a bit nicer, I guess. That again needs massive amount of standardisation which would permit swapping one tookit/program/library out with another version without causing any degradation in functionality. Just like it works in hardware world - As long as you have internet router that provides neccessary services, it doesn't matter is it a Cisco, Linksys or Slackware box

src2pkg creates the slack-required file on-the-fly, but it depends on everything being installed within a package. In other words, if a package depends on something that was installed simply using 'make install', then src2pkg, of course, can't tell which package it belongs to. src2pkg also has the ability to add arbitrary deps to the list -so that man-needs-groff and other such one-off dependencies can be dealt with.

Other distros could be accomodated in a similar way -adjusted for the different package database, of course.

I really don't blame PatV for avoiding the trouble, though. It *is* a big mess to actualy try to resolve depends when installing packages -and it would require some changes to the contents/inclusion of certain packages. For instance, the aaa_elflibs package would be particularly troublesome since it duplicates some files from many other packages. And big changes would have to be made to pkgtools.

With dependency resolutions, it feels like being pushed by some else, and that's definitely not what I want my system to be.

I'm surprised nobody has yet mentioned xkcd and the locusts. It really explains everything in one simple picture.

http://xkcd.com/797/

Does src2pkg rely on ldd, like other attempts I've seen? If so, what about dependencies which aren't shared libraries? For example, what about perl/python/ruby dependencies. Does it inspect the scripts to determine what they require/import/include? What about if they make a system() call to a command-line utility that is expected to be installed, can it automagically find that and mark it as a dep? What if it happens to be an optional dependency that doesn't apply to the current platform. Is it smart enough to not require it then?

As I mentioned before, attempts have been made at automated dependency tracking in the past, but there is no generic solution and many will fail silently in the cases I describe above. In this case, failing means you can break a package without warning, or install a package that can't work.

Since someone brought up XKCD, here's another reason dependency tracking can fail: http://xkcd.com/754/

1 members found this post helpful.

LOL. I like that one.

DragonWisard, src2pkg does not use 'ldd' -it uses a script (_ldd) I wrote which uses objdump to find the 'NEEDED' dependencies with output similar to ldd except that it needs less parsing than the ldd output. Using objdump is a safe way to determine the depends -ldd actually executes the object being tested which can be dangerous.

For additonal dependencies (like ruby, perl or whatever), you simply add a line to your *.src2pkg script like this:
ADD_REQS=perl.perl-xml-parser
src2pkg will still determine the list of lib dependencies, then adds whatever you have in ADD_REQS to the end.

As for automatically determining dependency on scripts, perl or other, it could be done automatically, but is quite involved, so I've never implemented any of that. It would be difficult to make it cover enough cases to be useful, and it could never handle other depends characteristics -I mean like 'suggests', 'conflicts', 'replaces'. These can be handled manually as above for ADD_REQS in the rare cases where that could be useful. 'man' is a good example, because it requires the binary 'groff' and it's scripts, and suggests installing 'man-pages'.

"What if it happens to be an optional dependency that doesn't apply to the current platform. Is it smart enough to not require it then?" Here I guess you mean a 'suggests'. lib dependencies are determined at compile/built time and will vary according to the configure options and/or what is installed on the build system at built-time. This is why it is (mostly) useless to try to use depends info from 3rd-party sources like using salix depends files or even sbopkg queues. If you build with other options the info may no longer be valid. And, the sbokg queue files are of no help for any package which is 'official'.

perl, ruby and python can probably all be used to find their required modules, but that gets rather involved. rpm includes some tools which will find some of those -and even html-page dependencies. That's a little far for me, I think. rpm can also find which programs are needed by bash scripts -that depends on a patch to bash. I use this patch myself on my boxes, but src2pkg does not use the feature -it would only where where the patched bash was available.

While fascinated by the problem of resolving depends, I still try to keep it simple. For my uses, I let src2pkg ignore glibc entirely -it never gets shown as a dependency(configurable src2pkg option). This way, in my database there are binary packages with no dependencies at all -the fact that no slack-required file is present tells me something about the package. I also simplify about using version numbers for the required package (also configurable). You can also have it ignore the aaa_elflibs package as it causes lots confusion when computing depends. There is only one or two libs in aaa_elflibs which cause a bit of a problem -primraily libgcc_so. If ti were not in aaa_elflibs, then depending on it would mean having to install the big gcc package. Nowadays there are a couple of other libs in there which are part of the compiler package(s). There is also cxx_libs -but it is already in its' own package. Upshot is, I package libgcc_so and the mudflap & Co. in a their own small package and use no aaa_elflibs at all.
I've written a couple of small utils which parse the database, so that: `pkg-reqs package-name` shows me a list of the packages which the package requires. `pkg-deps package-name` shows the list of packages which depend *on* package-name, if any. I haven't tackled actual resolution of dependencies while installing in my package tools, yet, but it is coming...

yuuko, You say: "it feels like being pushed by some else". Doesn't being told you should 'install everything' make you feel the same? What if you don't want or need a full system? "remove packages till something breaks, then backtrack and repeat" is not very useful either.

1 members found this post helpful.

Thanks didnt know about objdump, only 'readelf -d' (grep NEEDED)