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

It's called /opt

[LeninZhiv]

I'm sure many will correct me if I'm not hearing you right, but it should be noted that there is a widely-accepted and fully GNU/Linuxy way to have an application housed with its own directory tree (organised however the application wants) in /opt.

The filesystem hierarchy standard also provides /usr/local in cases where the UNIX filesystem hierarchy is adhered to (with /usr or even /. used if the software is included in the default disto/UNIX version).

This scheme has no advantages.

[Luarvic]

OK, Let's count advantages and disadvantages of proposed software installation system.

Advantages:

• You can easily know which files belong to which software packages
• You can easily remove the entire package by using simple rm -r command

All these goals can be easily achieved using any reasonable package menegement system. Now let's see disadvantages:

• Every time you install package you have to change PATH variable. Existing applications must be restarted to see this change, because environment variables are inherited and can be changed on-the-fly only if application itself is shell or has some shell-like functionality.
• Many packages have variable files (logs, data, caches, pipes etc.), which are normally placed in /var directory. Often /var resides on separate filesystem, because it has different requirements for speed, reliability, backup and other criteria. Under proposed schema we can not have separate variable filesystem.
• Shared library dependencies become a nightmare. If you have no version number in package directory name, you can not install different versions of shared library, so forget about compatibility with old packages. If you have version number, library moves to different place every time you upgrade package. Don't forget, that shared library version numbers do not necessarily reflect package version. Instead, they reflect ABI changes.
• Where are you going to have configuration files? If in the package directory, you must copy them every time you upgrade package. If for some reason you decide to remove package and than install it again, you lose all package's config files.
• You have problems if you decide to split package into subpackages. Directory structure changes and all applications which use programs or libraries from splitted package must be updated or restarted. The same problem exists when you unite packages together (like fileutils, sh-utils and textutils was united into coreutils package).
• Relying on PATH environment variable for invoking another programs is somtimes dangerous, especially for system services and set-UID programs. Usually full pathname is used in these cases. What kind of pathname can be used under proposed schema, if invoked program's package name can be changed (splitted into separate packages, united) or program can be moved from one package to another?

So, what we gain? Nothing. There are some advantages which can be easily achieved another way, but there are very serious disadvantages.
When managing system, stop thinking in terms of files. Think in terms of software packages. Consider /usr/bin a namespace which contains user-level programs and which is populated when packages are installed. Consider /usr/lib a namespace which contains libraries.

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.