Welcome to the most active Linux Forum on the web.
Go Back > Forums > Linux Forums > Linux - Software
User Name
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.


  Search this Thread
Old 02-28-2004, 08:40 AM   #1
Registered: Oct 2003
Location: West Midlands, UK
Distribution: Slackware 14 (Server),OpenSuse 13.2 (Laptop & Desktop),, OpenSuse 13.2 on the wifes lappy
Posts: 781

Rep: Reputation: 98
old chesnut of dependency hell, is there no end in sight?

Have been trying to update k3b from the Mandrake cooker ftp site using urpmi.
I am completely fed up with the problems of dependency. If the packagers know that I need package xyz to upgrade package abc, then why don't they just include it inside package abc. Urpmi is hopelessly lacking when it comes to this task. Even when it tells me that other packages are needed, and I agree to their installation, it then fails with telling me that there are package conflicts with previous packages of the same name, but with an earlier release No.
Is there no such thing as backward compatibility?
Can anyone tell me how to get around this problem, or do I just have to put up with it until Linux becomes a grown-up OS?
Sorry to rant on, but this is really starting to p*** me off. I have stayed away from MS for 3 years now, and have happily learnt how to compile software downloaded from source etc. Tinker with .conf files et al. But I'm not getting any younger, and could do with having a slightly easier life when I want to upgrade a piece of software. Am I the only one who sees this as a continuing problem? I would dearly like to see the demise of the monopoly known as Micro$oft, but I fear while these problems still remain, Linux will continue to be for the die hard amongst us, and I for one am ready to throw in the towel.
Old 02-28-2004, 12:26 PM   #2
Registered: Jan 2004
Location: Manitoba, Canada
Distribution: Debian
Posts: 454

Rep: Reputation: 32
There are a number of problems here:
1)There is no mechanism to prevent a developer or package manager from requiring libdfjhgh= .
2)Once that lib version is required by one package all the others that require something earlier or later will be in conflict. About the only solution is duplicate libs of different names...

One solution is that developers and package manager must have the discipline through some standard to only require libdfjhg>= This is backward compatibility and it could work except that from time to time there are major redesigns of a package. It is a pain to keep versions within versions to maintain backward compatibility after a major rewrite.

Another solution is that packages that require many libraries and links can be statically linked so that installation does not have as many requirements. Opera has that choice because they want more portability. Unfortunately, if every package did that, the size of /usr would balloon to overflow even today's large hard drives.

Another solution which may be the only one guaranteed to work now, is to have everything in source form and when you wish to install anything, rebuild it all. That is what the distributors do. This is approaching feasibility with the newest powerful machines and huge, fast drives and memory, but it is not possible for the ordinary user and his machine.

In the long run, something else must be done. I think there are just too many libraries and too much duplication. A particular developer can build and test his package, but there is no way to ensure that can be done on every Linux system. If the object of the game is to make Linux universal, some choices must be made. People who want to share libraries must agree to coordinate so that compatibility is assured. Either we need standardization on a finite number of libraries or we need to agree that rewrites will be coordinated. The diversity of the Linux community means that the maintainer of some light package and the committee in charge of the monster packages will have to agree to release code annually, or semiannually or whatever. This would mean that some would have to wait around for a release and others would have to work to a deadline, just like in the real world where some freedom is exchanged for efficiency. The developers should work from each other's snapshots, not the installing public.

Does this mean we need an umbrella organization to define a compatibility layer for Linux beyond the kernel? Yes. Instead of each distro struggling to patch stuff together a few times a year, with much wasted effort through duplication, we could have one committee of distributors setting the table of work and the distributors synchronize to them. The idea of sharing which is vital to Linux is based on not duplicating effort. Now developers, distributors and installers are all struggling with this mess, the ultimate waste. We need to share in a new way so that the end-user will be able to quickly install any current software on any current system. This change will require discipline but will save a great deal of energy at all levels.
Old 02-28-2004, 12:32 PM   #3
Registered: Oct 2003
Distribution: Debian GNU/Linux 9.0 (amd64) w/kernel 4.11.4
Posts: 287

Rep: Reputation: 30
What you advocate will only happen if it is developed using the standard community development model - otherwise the distro world might be divided into two camps: one who subscribes to this over-reaching compatibility system and the other, which does not.

But your basic theory is sound, IMO - you should package that up and post it on an LSB-related forum to get their feedback.
Old 02-28-2004, 03:35 PM   #4
Registered: Jan 2004
Location: Manitoba, Canada
Distribution: Debian
Posts: 454

Rep: Reputation: 32
Looks like the LSB is on track:

Packages shall have a dependency that indicates which LSB modules are required. LSB module descriptions are dash separated tuples containing the name 'lsb', the module name, and the architecture name. The following dependencies may be used.


This dependency is used to indicate that the application is dependent on features contained in the LSB-Core specification.

This dependency is used to indicate that the application is dependent on features contained in the LSB-Graphics module.

Packages shall not depend on other system-provided dependencies. They shall not depend on non-system-provided dependencies unless those dependencies are fulfilled by packages which are part of the same application. A package may only provide a virtual package name which is registered to that application.
This is from The current LSB draft

I think it means there will be no more dependency Hell, eventually. Unfortunately, I do not see x86 yet. They have two paths for developers to confirm compliance with sanity: a certification path suitable for the big guys involving money and one for the little guys who have to submit a test result from a verification programme that inspects the packages. It looks good, but I would bet it is still going to take some time. The thing that will get it adopted is that everyone will benefit. The little guys stuff will be able to install on all compliant distros, the big guys will be able to gain market share by advertising certification which will soothe customers, and the ordinary folks should find installation more like point and click...


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
please help me I'm in dependency hell baronsam Linux - Software 5 11-05-2004 09:33 PM
dependency hell riseringseeker Linux - Newbie 3 09-22-2004 01:57 PM
Dependency Hell :-( AMMullan Linux - Software 5 03-27-2004 10:51 PM
Dependency hell !!! lub0 Linux - Software 5 09-26-2003 08:17 AM
Dependency Hell Time Lord Mandriva 2 09-09-2003 03:48 PM > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 01:36 AM.

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