Bundled Applications for GNU/Linux?

munehiro asks: "As an addicted GNU/Linux and Mac OS X user I recently tried to install binaries and libraries on a Linux box using an approximation of the elegant and clean approach known as the Mac OS X bundle (everything about each app or lib under a different directory) as opposed to the Linux standard approach 'everything under a common prefix' (normally /usr or /usr/local) with applications and libraries mixed in the standard subdirs bin, lib, share and so on, and found administration life much easier. What do other, more experienced readers think about the problems and improvements related to dropping the current Linux approach for a 'bundle-like' one in Linux distributions?"

Comments

Re:Dupes in system...=space tradeoff

[Methlin]

How about the best of both worlds using hard links? As an added bonus uninstalling the last application that uses a particular library will remove the library as well instead of leaving it around as cruft. Of course this requires the libs and applications exist on the same filesystem.

Don't "path" bundle components!

[Jeremiah Cornelius]

This is the origin of DLL hell - which Windows has been trying to extract itself from for the past 6/7 years!

Also, executable content in arbitrary locations is a security nightmare...

Re:Dupes in system...=space tradeoff

[stuuf]

Sounds like what they did with GTK+ on windows. Apparently anyone who wants to install a GTK+ (other than GIMP) cannot be trusted to download and install GTK+ first, so they have to bundle it into the installer. So, once you install Gaim, GIMP, Ethereal, GTK Radiant, etc. you end up with 3 or 4 copies of the GTK+ libs scattered around (The most absurd one I've seen is Ethereal, which stuffs into the installer two versions of the app, one linked with GTK 1.x, the other with GTK 2.x, and both GTK runtime versions, for a plump 17MB installer). Whenever this approach is used, space is always wasted because of duplicates, and it makes it more difficult to update a shared library without reinstalling each application using it. Installing applications into their own separate locations does make administration easier. One of the only advantages to the current system is that you can have a PATH variable with a finite number of directories (/bin /sbin /usr/bin /usr/sbin /usr/local/bin /usr/local/sbin) and every application is quickly accessible from a shell command line. Now that many programs are launched form a desktop menu instead of the command line, this is not always needed. But bundling libraries with applications usually impedes maintenance and administration. It's also unnecessary because most package management systems (portage, apt, rpm, etc.) handle dependencies automatically (portage also has the depclean command to remove unneeded library packages).

Re:This scheme has no advantages.

[Blakey Rat]

Let's go over your list the OS X way. Noting that I'm not an expert:

1) PATH variable only applies to CLI applications. Apple solves this problem by putting CLI applications in the standard UNIX places.

2) /users/username/library/application support

3) Shared libraries cause as many problems as they solve. Modern computers aren't short on RAM or disk space and there's no need to use them.

4) /users/username/library/preferences

5) I have no clue what you're talking about on this one.

6) Bundles should be as self-sufficient as possible. The only external applications they should be calling are those that are *guaranteed* to be there.