Do you think the packager is lying to you?
Are you one of those people who install -current packages on the latest -stable release and then wonder why they won't work?

The information is available, and you just gave a link to it. The person who provided it is willing to maintain it, while the Slackware team is not.

The organization of the repo is mostly arbitrary these days anyway. That said, I won't rule out splitting of the xfce section - it's a possibility once xfce-4.8 is included.

BUT, RPM really depends on/use the SeaMonkey libraries!

So?
Do you think the directories in the repository were made to group packages because of their size? Can you explain the "tcl" and "y" directories, then?

I really don't understand your point. I use Slackware since 1998 and never had dependencies issues.

I was just illustrating a point to gnashley.
The point is: you don't have to touch the packages themselves to implement dependency info on the slackware repository.

As to willingness to maintain the info: I'm sure you ("the team" / Pat?) already have this info.
I mean: you must have it so you can build the packages in the right order.
And I seriously doubt that this info is not updated (maintained) regularly.
If so... why not share it?


That would be super!

Install the gtk+2 package from -current onto a 13.1 system. Then you'll understand.

Correct, and it's already done by someone who cares enough to maintain it.

Not really, no. Of course, we are aware that the information exists, but we don't need it, and we don't use it. It's simply not as necessary as many would have you believe.

Packages are built on a full installation, and we don't rebuild the entire distribution with every release.

See above. :-)

1 members found this post helpful.

Indeed it does, which is why Pat split off the seamonkey-solibs package and put it in the L series.

I gave the example of rpm depending on seamonkey libs as just one example of the surprises that having dependency info shows you.

As far as Stefano's work, I am aware of it -I think it is unmaintained now though. What I meant about needing to massage or manage the package content, was, that in order to provide any sort of real working dependency resolver. The best example I know of is the slackware aaa_elflibs package -its' presence and content poses some difficulties with dependency resolution which are bets worked out by not having the package at all. But, there is at least one library in it that otherwise causes another problem -the libc_s.so library. If it were not included in the aaa_elflibs package, then any program requiring it would require the full main gcc package installed -which is nuts for any kind of binary-only installation. The solution? -put libgcc_c.so in its' own package or with other small libs which come with gcc as a run-time-only package.

Don't get me wrong, I'm not suggesting or hoping that Slackware implement any of this -I've just spent a lot of time on it as a mental exercise -among other motives. Any quick look at the devs mailing list for debian or fedora will show you how much work they must do shifting things around and tweaking sources and build recipes so that their dependency-resolution schemes will work. If you think runtime-depends are a nightmare, study up on what is needed to do build-time dependency resolution! And rpm systems even have resolution of depends for scripts, html pages and other such items... Some of the tools are quite handy -rpm systems use a patched bash to list the calls in a script to external programs -nice when you have a long script and want to list all the proggies it needs.

I hope I know what you are actually discussing. Some people want things just work. Other want them to work their way. The latter may cooperate, create a distribution, take the code from developers and change it into whatever they find useful. The former want the developers to produce usable product, just like with Windows. The Slackware dependencies discussion originates in this divide.

Until some distribution becomes THE Linux distribution and ALL developers will be forced to develop for it under the penalty of eternal shame, the first group will never be happy. I also believe that until that happens Linux will never get beyond its magnificent 1% of desktop usage. This has not happen yet making the dependency discussion pointless.

It is OK to create yet another project to deal with dependencies on top of Slackware and play with it or discuss the relative virtues of such projects in a newbie forum, but are you sure the topic is relevant to the Slackware future?

Arguably such a project already exists in SalixOS. Its base is pretty close to Slackware.

If you feel they still stray too far from Slackware, you could still take their dependency information. You can find it here for Slackware 13.1: http://download.salixos.org/i486/slackware-13.1/deps/

Found this thread while searching for dependency checking, sorry to bring it back

I would love to have dependency info in the packages, because I want to know if a package can be uninstalled or not.

For example if i want to find out if i can uninstall package foo, i could make a script that would tell me "The following packages needs foo to function properly".

You could do this now. You don't need much of a script though, just download the SalixOS dep files linked previously for the core Slackware packages and grep against them.

Of course it won't tell you the whole story as others mentioned but it will tell you the SalixOS developers' feelings on what are dependencies. This will probably be good enough and if not it will at least serve as a starting point. In fact if you feel some of their dependencies off feed this information back as a bug report to them, which will ensure high quality dependency files for anyone who wants to use them.

Interesting. But I guess (I have never tried salix) that it wont cover all slackwares packages, only the ones salix has. Also I see on their website that they have patched some packages, does that mean extra lib dependencies as well?

1 members found this post helpful.