Talk:Dependency hell

Windows Add/Remove Programs Control a package manager?

Come on, is there anyone who really considers the Windows Add/Remove Programs Control a package manager? I think it shouldn't be listed as such. --Unsound 02:12, 11 December 2006 (UTC)

I agree. I'm removing it now. --Crashie 20:46, 25 February 2007 (UTC)

As an ex-user of GNU/Linux I demand one for Linux distros

Ever had your system broken because of weird unknown errors of missing libs or components in the middle of an emerge? Or ever had a crash in the middle of an apt-get upgrade? Ever used rpm? Ever had all hell break loose because of an soname change? (e.g. my horrible experience with libexapt.so.1 and Gentoo which a lot of people experienced). Well I think we need a section for those as well.

You "demand"? That's a good way to make people ignore you. -- intgr [talk] 09:37, 5 November 2007 (UTC)

Well, unless I'm mistaken, this article pretty much IS for Unix and *n?xes in the first place - every other popular system got their own article - and just about everything else is written Unix-centric (library names, version number explanations, etc.). -- Keilaron (talk) 15:00, 15 December 2007 (UTC)

You should have run revdep-rebuild — Preceding unsigned comment added by 82.70.28.30 (talk) 12:30, 14 April 2016 (UTC)

Internet access hell

In some distros, you need install new packages to configure Internet access, but you need Internet access to download the packages. This is a circular hell.--Mac (talk) 22:36, 5 February 2008 (UTC)

I suggest removing this section since it has nothing to do with dependencies, it's a matter of the installation process. Polaroit (talk) 12:47, 8 March 2008 (UTC)

Bad Examples of Dependency Hell

'DLL Hell' isn't an example of a 'Dependency Hell'.. it's one of naming conflicts. Namely, DLLs in Windows are located and bound based on their filenames along a list of pathnames, and that they don't allow for multiple versions to easily coexist. 'Extension conflicts' and 'JAR Hell' are similar problems. "Dependency Hell" can only very loosely describe these because they're problems that appear when attempting to bind to 'dependent' modules at runtime... but it's not the dependency per se that is a source of the problem. I think this entire article needs a deeper review to better clarify what "Dependecy Hell" is all about. —Preceding unsigned comment added by 24.150.186.96 (talk) 15:25, 1 July 2009 (UTC)

Mild vandalism

There seems to be some mild vandalism in the 'conflicting dependencies' subheading of 'Problems'. I don't think the phrase "pwnage" is really of the standard of Wikipedia. However, I agree that it is an apt description of the problem, and so I won't be the one to delete it. My computer said love (talk) —Preceding undated comment added 00:55, 14 January 2010 (UTC).

Glad to see the focus is back on Linux here

One of the comments in the edits now is "this problem has been resolved in Linux for 10 years". Is this person doing a straight install and never adding any more apps? Perhaps if you are using some pre-packaged RPM for the version of RedHat you are using, but I cannot believe that you are regularly compiling programs from source or using (even mildly) outdated RPMs and are not running into "dependency hell" to this day. This is a "feature" of Linux for users who spend any time at all with complex configurations and I and the Linux gurus I work with deal with this problem on server installs whenever a customer strays from the beaten pre-installed path and we need to replicate their setup. This problem is most certainly not "gone". Another arrogant comment - that it's all "user error" - might be true if you subscribe to the idea that users need to exhaustively research what key components are required for an install before attempting the install. Again, that's a type of "hell"... On the plus side for this article, Linux users can now laugh when a Windows7 user tries to install something from the Windows 95 or Win 3.1 era and runs into a problem with DLLs. Not that there is much to be proud of there with a 15+ year difference and a Linux RPM can be so quickly rendered obsolete. —Preceding unsigned comment added by 70.140.59.111 (talk) 12:42, 10 June 2010 (UTC)

"but I cannot believe that you are regularly compiling programs from source or using (even mildly) outdated RPMs"

Since when was compiling programs easy on other platforms?

That aside, the whole point of Linux distributions is that they take care of putting together the software and making sure that it works together. If you need older versions of software for some custom application, you should simply use an earlier distribution release. There are Linux distributions that provide support for older releases for many years, including security updates and bug fixes — for exactly this reason. Ubuntu Server LTS releases are supported for 5 years, RHEL and SLES for 7. All these distros have package managers (apt-get, yum and yast) to manage installation dependencies and updates.

Manually installing packages, and mixing and matching bits from different distribution releases is unsupported. If you do that then yes, you will run into dependency hell. And yes it is user error.

You'll also note that the sources in the article date back to 2004, 2003 and 2001. -- intgr [talk] 19:22, 10 June 2010 (UTC)

Dependency hell is far larger of a problem than most Linux fanbois would have you believe. Even at IBM, where Redhat Enterprise Linux rules the roost, often software which users would like to have installed, cannot be installed due to....you guessed it, unresolved dependencies. Sure, I could go compile my own software and find dependency rpm's in other repositories, but who's going to ensure all the security holes for all those dependencies get plugged? You guessed it, because they were installed outside of normal channels, they won't. — Preceding unsigned comment added by 24.91.145.17 (talk) 23:24, 10 May 2012 (UTC)

PC-BSD mention

Does anyone know enough about the PC-BSD PBI package management system that prevents dependency hell (see: PC-BSD#Package_management)? Could we add this to the article? TurboForce (talk) 19:18, 17 June 2012 (UTC)

Nobody else has added anything about this for over a month, so I will mention PC-BSD package management in the page, then other editors can add more to it. TurboForce (talk) 22:47, 19 July 2012 (UTC)

"Current package managers in Linux have largely solved this problem by automatically resolving and downloading dependencies."

This clearly shows the author has no idea what its about... Dependency and DLL hell come from incompatible versions often by people who do bad things eg if 2 authors changes a standard library but left the dll the same then its impossible for both apps to work without building sandboxes.. In Windows some developers would change standard C libs , redistribute them to system32 ( or in Linux /usr/bin) and not change versions etc - this vulnerability from people who create installers or packages is what its about.. this would also cause most Linux systems to also fail and have horrible pathing problems. The only system that comes close to handling this is .NET and to a lesser extent Java style bytecode files.

In addition there are many issues with packages as well and it would still be described as dependency hell. Code distribution and /configure and gmake are horrible and even worse. I would call .configure dependency hell . You sometimes get cases where one component needs to be later than xyz and another requirement will not work with later versions. — Preceding unsigned comment added by 180.157.75.21 (talk) 09:50, 29 August 2012 (UTC)

Poor Example in Examples section

The Gecko Runtime Environment and the software that depends on it is, as the article itself points out, a poor example of dependency hell because it is solved by bundling the GRE with every iteration. Dependency Hell is an instance where precisely this workaround cannot happen for one reason or another, otherwise it would be better described as Dependency Hiccup or somesuch.

Since the point of any example is to make the concept clearer, not muddy the waters through convoluted explanation of the details OR offer a counter-factual, I suggest this particular section be eliminated. — Preceding unsigned comment added by 96.50.69.215 (talk) 01:22, 18 January 2013 (UTC)

Agreed. The claims in the section has been marked as CN since august. Given the dubious nature and your point I have removed the section. Thanks. Useerup (talk) 06:13, 18 January 2013 (UTC)

Is there an article on dependencies in general?

This article is somewhere between the pessimistic and the pejorative. Dependencies exist, sometimes (and lately it's more often than not) there's nothing "hellish" about it. The Apache Ivy article has a redlink as both dependency manager and library dependency. That ought to be a blue wl, as it's necessary for explaining the need for Ivy. It shouldn't link here, as this article suggests that it's all entirely negative. Is there anything better, and less judgemental? Viam Ferream (talk) 12:44, 3 September 2014 (UTC)

another soltuion

compile the dependency statically, remove the dependency :p Divinity76 (talk) 01:57, 8 February 2015 (UTC)

Package Manager Dependencies

The "Package Manager Dependencies" section is currently one long, long, sentence, which I cannot parse or understand. It needs an overhaul. Perhaps it is missing some of the text? — Preceding unsigned comment added by 76.198.131.49 (talk) 18:57, 10 February 2016 (UTC)

Wow. That was pretty special. I've deleted it as the content here was absolutely unreadable, the reference supporting it was little better and there's no clear indication that package managers like yum or apt bring in any new sort of dependency hell, above what was already there manually. Viam Ferream (talk) 09:18, 11 February 2016 (UTC)

It's just blogspam and already keeps coming back. Viam Ferream (talk) 11:15, 11 February 2016 (UTC)

@Viam Ferream: I agree with your edits, but your edit summaries could use improvement. Rather than attacking people with "Blog spamming. Learn to write something vaguely comprehensible before spamming it here.", you could explain that most blogs are not reliable sources and if they think they have a relevant point, they could explain it in more length on the talk page. In most cases they won't bother, but it can be helpful to avoid edit wars. -- intgr [talk] 11:43, 11 February 2016 (UTC)

Spamming a blog is still spamming. This is barely literate and of zero value here. It just doesn't belong. Are you going to start hiding all my edits on this page too? Viam Ferream (talk) 12:47, 11 February 2016 (UTC)

3rd party distributors

I have an issue with the text in parenthesis in this phrase:
"A problem on Linux systems with installing packages from a different distributor (which is not recommended or even supposed to work)..."
Given the Linux file structure specifications of what /usr and /opt are intended for, surely it can't be said that installing packages from a different distributor is not supposed to work. --Varybit (talk) 08:39, 8 May 2019 (UTC)

Licensing Law Domain

Dependency Hell in Law Domain affecting final License terms,

or preventing of estabilishing Final License terms, producing software / hardware unlicensed.

I would like to see such See also Link, that would explaind dependency hell in Law Domain. 79.187.34.81 (talk) 15:19, 1 November 2022 (UTC)

Introduction

The introduction says "Dependency hell is a colloquial term for the frustration of some software users..." But dependency hell is much more than just a "frustration" of "some users". It happens very often in for more complex software configurations where flexible version numbering is allowed. Often these flexible bounds are also incorrect, eg a dependency may require "version>=2.3.0" but it never considered that incompatible revision 3 would appear. In the worst case, dependency hell causes software to break completely, resulting in crashes, or failure to install the software. And it can also cause automatic software installers to get into an infinite loop, causing the system to hang on the install or upgrade.

I suggest making the introduction much more serious than it is. 131.180.250.27 (talk) 14:47, 17 April 2024 (UTC)