LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware
User Name
Password
Slackware This Forum is for the discussion of Slackware Linux.

Notices

Reply
 
Search this Thread
Old 08-15-2011, 08:49 PM   #31
ReaperX7
Senior Member
 
Registered: Jul 2011
Distribution: LFS-SVN, Slackware-14.1, PCBSD-10.0
Posts: 2,786
Blog Entries: 15

Rep: Reputation: 729Reputation: 729Reputation: 729Reputation: 729Reputation: 729Reputation: 729Reputation: 729

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.
 
Click here to see the post LQ members have rated as the most helpful post in this thread.
Old 08-16-2011, 12:37 AM   #32
lumak
Member
 
Registered: Aug 2008
Location: Phoenix
Distribution: Arch
Posts: 799
Blog Entries: 32

Rep: Reputation: 109Reputation: 109
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.
Old 08-16-2011, 12:29 PM   #33
vdemuth
Member
 
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),Suse 13.1 (Desktop),, Mepis on the wifes lappy
Posts: 764

Rep: Reputation: 92
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
 
Old 08-16-2011, 12:51 PM   #34
DragonWisard
Member
 
Registered: Sep 2004
Location: MD, USA (D.C. Suburbs)
Distribution: Slackware
Posts: 95

Rep: Reputation: 53
Quote:
Originally Posted by vdemuth View Post
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).
 
Old 08-16-2011, 01:31 PM   #35
dugan
Senior Member
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 4,539

Rep: Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385Reputation: 1385
Quote:
Originally Posted by DragonWisard View Post
1) Nobody would ever agree on a standard way to describe dependencies.
There really already is one. The slack-required file.
 
Old 08-16-2011, 01:35 PM   #36
DragonWisard
Member
 
Registered: Sep 2004
Location: MD, USA (D.C. Suburbs)
Distribution: Slackware
Posts: 95

Rep: Reputation: 53
Quote:
Originally Posted by dugan View Post
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.
 
Old 08-17-2011, 06:45 AM   #37
wigry
Member
 
Registered: Jul 2004
Distribution: slackware
Posts: 217

Rep: Reputation: 52
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
 
Old 08-17-2011, 01:24 PM   #38
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,746

Rep: Reputation: 458Reputation: 458Reputation: 458Reputation: 458Reputation: 458
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.
 
Old 08-17-2011, 01:25 PM   #39
yuuko
Member
 
Registered: May 2011
Distribution: Slackware-current
Posts: 42

Rep: Reputation: 20
With dependency resolutions, it feels like being pushed by some else, and that's definitely not what I want my system to be.
 
Old 08-17-2011, 01:51 PM   #40
55020
Member
 
Registered: Sep 2009
Location: Yorks. W.R. 167397
Distribution: Slackware
Posts: 300
Blog Entries: 4

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

http://xkcd.com/797/
 
Old 08-17-2011, 02:18 PM   #41
DragonWisard
Member
 
Registered: Sep 2004
Location: MD, USA (D.C. Suburbs)
Distribution: Slackware
Posts: 95

Rep: Reputation: 53
Quote:
Originally Posted by gnashley View Post
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.
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/

Last edited by DragonWisard; 08-17-2011 at 02:46 PM.
 
1 members found this post helpful.
Old 08-17-2011, 02:21 PM   #42
sycamorex
LQ Veteran
 
Registered: Nov 2005
Location: London
Distribution: Slackware64-current
Posts: 5,524
Blog Entries: 1

Rep: Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997Reputation: 997
Quote:
Originally Posted by DragonWisard View Post
Since someone brought up XKCD, here's another reason dependency tracking can fail: http://xkcd.com/754/
LOL. I like that one.
 
Old 08-18-2011, 03:34 AM   #43
gnashley
Amigo developer
 
Registered: Dec 2003
Location: Germany
Distribution: Slackware
Posts: 4,746

Rep: Reputation: 458Reputation: 458Reputation: 458Reputation: 458Reputation: 458
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.
Old 08-18-2011, 06:25 AM   #44
sahko
Senior Member
 
Registered: Sep 2008
Distribution: Slackware
Posts: 1,041

Rep: Reputation: Disabled
Quote:
Originally Posted by gnashley View Post
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.
Thanks didnt know about objdump, only 'readelf -d' (grep NEEDED)

Last edited by sahko; 08-18-2011 at 06:29 AM. Reason: typo fix
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] why does slackware's package manager purposely not resolve dependencies? Cultist Slackware 93 06-25-2010 04:02 AM
how to resolve rpm dependencies offline ? vermissa Linux - Software 1 11-20-2008 01:37 AM
resolve dependencies in lfs tomave Linux From Scratch 1 03-12-2006 02:57 PM
apt-get: don't resolve dependencies? merchtemeagle Debian 7 06-17-2005 02:11 PM
does pkgtool resolve dependencies? mcd Slackware 3 05-31-2004 09:38 AM


All times are GMT -5. The time now is 11:27 AM.

Main Menu
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
identi.ca: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration