Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

Different OSes have different standard way of installing package dependencies; in OS X, all library dependencies are copied in the App folder.

Windows application developers have both options; they can install a library as a subpackage (for example, game installers would install directX library). But usually the user cannot choose if he wants the dependencies to be copied or be shared on the system

In Linux, package managers (for example, apt-get) will resolve recursively the dependencies and install them system wide. This of course, doesn't necessarily solve the problem of dependency duplication, since applications might still use different versions or builds of the same source library

For instance, some applications will require libboost-filesystem1.42 but damn, I have libboost-filesystem-1.49 available, but that won't help because the package resolver can't figure out that I already have one.

On the other hand, I don't want an old library being installed in system-wide paths, because I have already another version in there.

Question: is there, or will there be a standard package manager option to allow dependencies for certain applications be installed in application-specific folders (like App folders in Mac OS X)?

share|improve this question
add comment

1 Answer

You've got it wrong: “old” libraries are installed on system-wide paths, and this is the desirable behavior. The way it works is: if two library versions are compatible at the binary level, then you only have one installed, and every application that uses this version uses the same library file. If two library versions are not compatible at the binary level, then you have multiple copies installed, each under its own name, and applications requiring different versions of the library each use the appropriate library file.

For example, if you have libboost-filesystem-1.49 installed (in /usr/lib/libboost_filesystem.so.1.49.0), that doesn't help an application that requires version 1.42.0, because the binaries are not compatible. That application requires /usr/lib/libboost_filesystem.so.1.42.0. Package managers will automatically install the required version of the library when you install an application. If you have an application that requires 1.42 and one that requires 1.49, you'll have two different versions of the library in /usr/lib, each with its own file name so they can live together in peace. Most package managers today can also automatically uninstall library versions that are no longer used by any application.

Installing libraries in application directories is a poor-man's way of handling dependencies, used on operating systems that do not have good package management and distribution channels. To make things work without hassle, they bundle every library required by an application with the application itself. This means you end up with multiple copies of the same library version, and there is no easy way to upgrade libraries — you end up with multiple obsolete copies of the same library.

There isn't and will not be an option to install libraries in application directories because having a package manager means you don't need to do that.

share|improve this answer
    
And the reason that there are two different packages of libboost_filesystem.so is because the libboost developers screwed up and broke backward compatibility. Library maintainers are supposed to maintain backward compatibility as with all previous minor revisions so that applications written against 1.42 will work with 1.49. If you must break backward compatibility, you are supposed to do so with a major revision, then libfoo1 and libfoo2 can exist concurrently temporarily, until all apps have been fixed to work with libfoo2, then libfoo1 is removed. –  psusi May 14 '12 at 23:31
    
when i was a kid i always wondered why my family's computer had like a zillion different versions of the same library... now i know why! the OS sucked! –  ixtmixilix May 14 '12 at 23:44
2  
@psusi Not everyone adheres to the convention that versions have the format MAJOR.MINOR where a change of MAJOR breaks binary compatibility and a change of MINOR doesn't. Another popular convention is MAJOR.MINOR.PATCHLEVEL where MAJOR changes when source compatibility changes and MINOR changes when binary compatibility changes. As long as the people who build applications and packages follow the rules given by the library authors, this is purely a matter of convention. –  Gilles May 14 '12 at 23:56
    
The patchlevel is supposed to be for bug fixes ( patches ) that don't break compatibility, OR add new features. –  psusi May 15 '12 at 0:00
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.