Linux - SoftwareThis 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.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I understand them being used back in the day when we had to save every bit of space imaginable.
I also concede that compiling on different machines might give you a different output.
But these days, custom compilation yields very little improvement, and we have terrabytes of space.
So,.. why dont package maintainers just package up EVERYTHING they need in one package, instead of relying on dependencies?
Instead of Openoffice relying on Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486, and breaking when that package can't be found, why doesn't the programmer using Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486 just copy that all into the Openoffice source tree and call it a day? Why depend on the niceties of package maintainers and goodwill from other projects?
Pull in what you need - make it work - distribute it. Stop with the 'I need this one 2 line function from version 12.83.1323.99a-b of foo.alpha-x86.el2 and my program will NOT compile without it!' nonsense.
Its a thought anyway. Sure there are a million intricate reasons why packaging and installation can't be simplified, and a million more why we need dependencies still.
Anyone know the reasons?
Last edited by Tinkster; 11-06-2014 at 02:15 PM.
Reason: language cleanup ...
Instead of Openoffice relying on Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486, and breaking when that package can't be found, why doesn't the programmer using Erlang 1.2.3.141.9.222-buld00001.alpha.centauri.486 just copy that all into the Openoffice source tree and call it a day?
Projects that build and distribute their own binaries usually actually do that. (Or they statically link, which is letting the compiler do the same thing). OpenOffice is an example. So are most games, including those on Steam, GOG and the Humble Store.
Suppose a bug or security problem is found in a library. Would you rather upgrade one shared library, or tens of applications which are statically compiled with it? Consider that each application upgrade is likely to have new features, new bugs, changed functionality, perhaps a redesigned user interface. Wouldn't that be fun? Not.
I imagine, If everyone started packaging their own libraries and dependencies in their application:
They would be responsible for security updates, as many of them are now anyway
They would push out updates, which many of them do now anyway
Each program might end up using a different version of said library - possibly skirting the vulnerability by way of version,
Something like that.
Got me thinking. Currently, most things use shared libraries right? So, if the library is a security vulnerability, every single thing on the box that uses it is vulnerable. Possibly 100's of programs. Whereas if a program was pacakged with everything it needed, it might come about that only that version of the library is vulnerable, but only one program is using it, rather than 100's sharing it.
Perhaps.
Last edited by szboardstretcher; 11-05-2014 at 06:22 PM.
I don't think static libs are a good idea. Like said above, if something changes you'll have to recompile everything. It would also be harder to maintain, and would be less secure because it would take time for them to patch their local version, which may be out-of-date and the patches would need back-porting.
Shared libraries have many advantages and that's why they are used in most cases. The only cases where I don't like it is small libraries that don't even need to exist. I know some small projects like to separate part of their code into libraries, but nobody uses these libraries except for the program they wrote. I guess they are hoping someone would use it.
All software packages and dependencies are installed in their own self-contained directories in /Programs. This convention is aimed to decrease confusion about where binary programs reside, remove the possibility of a package breaking if system libraries are upgraded or changed, and prevent dependency hell.
So, if the library is a security vulnerability, every single thing on the box that uses it is vulnerable. Possibly 100's of programs. Whereas if a program was pacakged with everything it needed, it might come about that only that version of the library is vulnerable, but only one program is using it, rather than 100's sharing it.
Perhaps.
And why would that be better? You can upgrade OpenSSL and fix the vulnerability in hundreds of packages immediately, or you can depend on the maintainer of each of those hundreds of packages to individually notice and tell if they've been using a vulnerable version of OpenSSL.
But there has to be *some* way to make it less of a pain-in-the-ass to install a package, without the dependency calculations required currently.
And, with that link, it certainly seems like other people have been thinking about the issue as well. That's good. If it's being thought about, talked about and tinkered with, then someday the packaging ecosystem might be more homogenous and less prone to the dependency hells that exist.
What dependency hells? I've had to do a bit of juggling with stuff for CentOS from other distros, but that's a penalty of using such a small distro. When testing distros (and I've used 114) only the obscurer ones have had problems with software installation. Except, that is, Debian. Does your profile's "GNU/Linux" entry indicate that you're a Debian user?
Does your profile's "GNU/Linux" entry indicate that you're a Debian user?
Just identifying myself with Linux in general. I've used many (112.5 +- 2%) over the years, and have many different distros that I have to feed at work. I also have a couple of solaris boxes and an AIX db server.
Quote:
What dependency hells?
Assuming you are using a package manager like yum, you might not see the various levels of horrific dependency requirements and collisions that happen still to this day. This happens more often when installing software from source - which is the reason that I prefer the handful of programs that come with everything that they need rather than depending on external packages.
I think some of dependency hell is caused by programmers' carelessness when choosing dependencies. I know a number of programs that could reduce their dependency list, especially to less esoteric dependencies that are not well maintained and are hard to install. Please consider this when writing programs and choosing dependencies. I mean, here's a concrete example: OGRE. Yeah, if you've ever tried to install it, you'll be missing some hairs on your head.
I think some of dependency hell is caused by programmers' carelessness when choosing dependencies. I know a number of programs that could reduce their dependency list, especially to less esoteric dependencies that are not well maintained and are hard to install. Please consider this when writing programs and choosing dependencies. I mean, here's a concrete example: OGRE. Yeah, if you've ever tried to install it, you'll be missing some hairs on your head.
I haven't tried to install it, but the Slackware packaging script doesn't look too complex to me:
Assuming you are using a package manager like yum, you might not see the various levels of horrific dependency requirements and collisions that happen still to this day. This happens more often when installing software from source
If you're trying to build your own debs or RPMs, yes. If you're just doing ./configure ; make ; make install or building for a distribution that doesn't enforce dependency versions (Slackware, Arch, Gentoo, etc) then no. The build system detects the dependencies that are present on your system.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.