Hi.

I installed my Slackware with out of X. I then realized I need it, so I installed X and firefox with ``slackpkg`` and firefox did not work because one of its shared object dependencies were not satisfied.
I checked it with ``ldd`` and found name of lib (I do not remember exactly, let it be libFoo.so). So I used ``slackpkg`` to find package that provides this library and installed it.

I did it several times going transitionally through dependency tree and I finally got my firefox working.

My idea is to create tool to automate this process by providing list of packages that are *absolutelly required* for certain one. Do not install them automatically, just list them. You then pipe its output to slackpkg install and it simply works. (I can do such tool with python or C).

As far as I understand, Slackware does not like dependencies for 2 reasons:

* They are huge. In some RH-based distros I install munin and it installs perl automatically because munin-cgi-graph is written with perl. It is not an issue with my approach since only *necessary* packages are installed.

* Developers are required to manage them. In my case they are managed automatically.

What is wrong with my idea?

Not sure this is exactly what you are looking for, but you can find missing libraries as reported by ldd with this script.

https://notabug.org/orbea/SlackBuild...ipts/brokenpkg

Note that there are some false positives, as with firefox. Also it will not help with non-compiled programs, such as python and perl modules.

It's not a matter of whether slackware does or doesn't like dependencies. There isn't a "dislike" of dependency management in the slackware approach. What you'll find is that after a while, and slackware user will find out, just like you, how to deal with them. And in that, you'll find why me and others stick with the distro. Because dependency tracking built into the distro's package manager eventually gets in the way, and causes unforseen consequences created by the distro package builders. When dependency management is not required by the package manager, then the user can fulfill the library dependency in the way the program is designed to use it, as you see in the ldd command.

1 members found this post helpful.

Sounds similar to sbbdep, although that does not have slackpkg in the loop. I say go for it. The worst that happens is it's only useful to you, but if it works well, I'm sure others will use it also.

Anyway, as the3dfxdude said, I don't think Slackware is inherently against automatic dependency resolution, just overcomplicated package managers that make it impossible to do what you want because they "know better than you."

One more comment: your approach will not be able to capture other types of dependencies like Python modules.

1 members found this post helpful.

slackyd

http://slackbuilds.org/repository/14...search=slackyd

+1 what the3dfxdude said!

Several distributions based on Slackware need such a tool because they do not ship a full set of Slackware packages on the installation media and/or to ease installation of third party or more generally packages not shipped in Slackware.

Salix, Slackel and Slint use depfinder written by George Vlahavas:
https://github.com/gapan/depfinder.

Other tools provide similar features like sbbdep:
https://bitbucket.org/a4z/sbbdep/wiki/Home

The Salix project provides dependencies lists for Slackware packages for each stable Slackware version since 13.0, for instance you will find the dependencies lists for Slackware version 14.2 (64-bit x86_64) here:
http://slackware.uk/salix/x86_64/slackware-14.2/deps/

The results given by the tools that find dependencies should be carefully reviewed for at least these reasons:
- the dependencies on programs written in scripts like perl, python and ruby aren't always found, or not in a 100% reliable way,
- the results may depend on which packages are installed when the tool is used,
- they also depend on optional features set when building the packages.

And of course dependencies needed at build time are another topic.

2 members found this post helpful.

Didier, you just explain WHY the package builder should write himself the dependencies list at build time...

No dependency listing system is perfect.
Salix lists most packages' dependencies, but you can't find the "noarch" ones in there.
ldd is useless for packages like slackpkg or pkgtools.

When's the last time you removed something from your system that broke slackpkg or pkgtools? I think if you run into that problem you have bigger issues than investigating missing dependencies...

I think you are missing the point of having a list of dependencies for slackware stock packages...

Yes, I don't see the point in having an exact list of dependencies for basic shell scripts. If you really wanted one, read them and take note of all the binaries the scripts call.

Well, devs, hwdata, kernel-firmware (to name a few) are not shell scripts... yet, I assume they are there because something else needs them ;-)

Also, you can use ldd and similar tools to find out binary dependencies of a binary package far easier than reading a complex shell script like slackpkg and keeping track of its dependencies.
What is your point? That we should do all tasks manually instead of having a tool that automates boring work? Strange notions from a computer user...

I, for one, would welcome a list of dependencies (hard and optional) for all stock packages in Slackware (including the "noarch" ones).
There are no downsides to having one.

I never said anything about hwdata or kernel-firmware, I was responding about pkgtools and slackpkg which are shell scripts. Ldd will not print the dependencies for shell scripts so there is a downside, someone would have to do the work to create and maintain the list. There also would not be any real gain, Slackware has worked well this way for a long time.

I guess you could make a shell script to look at other shell scripts, compare every word in it and compile a list of binaries. Sounds way more effort than it would be worth.

The word "dependency" usually refers to shared objects on which some binary depends.

-noarch packages have no dependencies using this definition, as they include no files in /usr/lib or /usr/lib64.

If you use the word dependency with another meaning, you will have to define it.

If for instance you speak about all programs that a shell script needs to run as intended, you will have to analyze the the script to find what utilities or other programs it runs or calls. If you write a program that does that automatically, please share it with us.