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

darwinports

[russellh]

I think DarwinPorts is working on something like this. Unless I'm mistaken of course...

Correct me...

[Doctor O]

...but to me it seems that the approach is the way to go. Install/uninstall by cp/rm or drag/drop, whatever you prefer. Ressource waste definitely is no reason for today's machines, at least on the desktop.

Mostly great

[WMD_88]

It's great to work with...simple as hell. But, I wonder...what if a lib needs to be replaced (updated), will all the bundles get the new version?

GNUstep has, and always will, do this

[aperezbios]

Hi there,

GNUstep (http://www.gnustep.org) applications use application bundles as well. This tends to piss off a lot of anal-retentive folk, especially in the anal-retentive Debian Developer reality, but we do it because it ACTUALLY MAKES SENSE. It doesn't make sense to have stuff for one app in ten different non-parentally-unified folders.

I strongly suggest you check it out, if you've not previously. I'd personally like to see a unified AppBundle Freedesktop standard. Rox also uses AppBundles, as far as I know, and it would be nice to have a unified and mutually agreed upon format for them. Maybe you'd be up to the task of coordinating it. If so, subscribe to the gnustep-discuss mailing list (see the website for a link) and let's see what we can work out.

Re:GNUstep has, and always will, do this

[Bat_Masterson]

Of course, the problems with this is that, if everyone follows this approach, then PATH variables can become HUGE! Also, there can be unintended side-effects in the ordering of the PATH variable.

Try Gobolinux, or GNU Stow

[forsetti]

Gobolinux: http://gobolinux.org/
Stow: http://www.gnu.org/software/stow/stow.html

I think you will find that you are not alone ...

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.

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).

Re:It's called /opt

[thegrassyknowl]

It's possible to build and install a package into /opt/packages/packagename-1.2.3.4/[bin][lib][sbin]

And then symlink anything that it would have installed in /usr/[bin][lib][sbin] back to /usr/local/wherever. It makes removing the package pretty easy. Remove /opt/pacakage/packagename-1.2.3.4 and then check /usr/local for dangling links...

Then there is only one copy of programs, libraries, and everything else but its all symlinked so that the packages can be all contained within their own dir.

Global updates

[SanityInAnarchy]

To what extreme does this go? For example, where is the standard C library?

Suppose there's a major security flaw in a reasonably popular library. If each package must keep everything inside its own folders, then the library update only goes to apps which are maintained actively -- and which noticed that the library was updated.

If, on the other hand, we use traditional UNIX, then one file is replaced in /lib, and at worst we get a warning that something some program is doing with that library is depricated and will be removed. But this gives the individual program maintainers more time to update, because they don't have to rush things out the door to make the security patch. They have until the next library release to get with the program.

And, resource management DOES matter. There is no good reason that my dad, a commodity/stock broker, needs 512 megs of RAM on his machine -- except for the use of this kind of design. It's not just how much memory it takes up on disk, if you have to load glibc fifty times into RAM, you've got problems.

I couldn't care less!

[Roadkills-R-Us]

I've worked on OSes that used both methods, as well as others. Either of the two mentioned here is fine. You just spend a few minutes learning how your system does it, and deal with it.

There are, IMO, much better uses of good engeineers' and programmers' time, than fighting this battle.

Any logical approach, that's my preferred approach. And both of these are logical enough.

Doesn't scale well

[Anonymous Coward]

For each application I would have to add an entry to
PATH and possibly LD_LIBRARY_PATH, either globally or (even worse) in each user's profile file.
With package management systems such as dpkg and rpm maintaining the /usr hierarchy, I don't think there is any advantage in moving each library/application to
a different directory. There is even software available that will track where files are placed when locally compiled
packages are installed. So, where's the advantage? I see lots of
drawbacks and no real benefits.
I generally follow the rule that software installed under /usr should be maintained entirely by the package manager; locally compiled software belongs under /usr/local.

Re:Dupes in system...=space tradeoff

[Bat_Masterson]

You can have the best of both worlds with symbolic links. A tool like Pkglink can do most of the heavy lifting and also give you the ability to have multiple versions of the software installed.

Solve the right problem

[Rysc]

App bundles are okay for some people, but they are not the holy grail most seem to be touting them as here.

Sure, library updates are a problem. But that isn't why app bundles are a bad idea.

App bundles are a bad idea because they solve more problems than exist, and cause more problems than they solve.

For every definciency in the way UNIX traditionally works there is a workaround. The problems with the system are well known. The system has a very few flaws... but one of those flaws is really glaring to desktop users, especially Mac heads.

Because they see only what is broken and not what isn't they propose a Mac-like system. The app bundle idea isn't new and it isn't bad, but it does not solve the right problems. It solves one, perhaps two, problems, mostly for one class of users. And, while those problems are being solved, it creates dozens of difficult problems for several classes of users.

The people who have the new problems tend to be the uber-admins, the developers, and the people who create distros. Those people do not adopt app bundles because the "sense" that they make is non, from thei point of view. In a admin-centric cost-benefit analysis app bundles nearly always lose to the *nix way.

If someone could figure out a way to solve the problem that app bundles solve for desktop users without screwing over the admins and developers, distros would convert in droves. Since the existing solution is to "Screw different people, screw more people, just unscrew ME!" no one really feels obliged to comply.

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...

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.

Re:This scheme has no advantages.

[cowbutt]

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.

Sadly, libraries aren't similarly short of security problems. This is what happens when a library that is commonly statically linked is found to have a security vulnerability.

Not even worth discussion.

[Ogerman]

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?

OK.. this question is really 1st year CS material, so hopefully this will set all y'all newbie young'ns straight. "Bundling applications," as defined as giving every app it's own copies of used libraries, is just plain stupid if at all avoidable. Here's why:

1.) What happens when a bug or security flaw is found in a library? Without a shared copy, you must figure out which apps are using it (which may be thousands) and then upgrade every application "bundle" instead of one library for the whole system. And what if some apps are using an older version of the library which nobody bothered to patch?

2.) Disk caching. Today's hard disks may be really large, but they're still really slow (compared to the rest of the system). If you have to load separate copies of a library for each app, you lose all the benefit of disk caching.

3.) Memory usage. Shared libraries allow a single copy of the library in memory to be used by multiple applications. This also reduces load time if the library is already in memory. (ie. this is why it makes sense efficiency-wise to use either KDE or GNOME and not a mixture of apps from both) It's also partly why OpenOffice and Firefox take so long to load on Windows compared to Office and IE. (they don't use all the standard windows libraries.)

4.) Shared libraries are a major driving force in pushing application developers to stay on their toes and keep up with the progress of the library developers.

5.) You shouldn't be compiling your own apps unless you're their developer or have very specific security or optimization needs. It's a waste of time unless you're learning something in the process. Leave that job to distro package maintainers and do something useful with your time like becoming a better programmer and/or contributing to your favorite app. Once Linux ceases to be a toy for you, you'll avoid compiling everyday software like the plague.

I could go on for several points, but that should be enough to convince ya. (:

Re:Not even worth discussion.

[calica]

I'm wasting mod points replying but this needs to be said.

App Bundles can be configured to search installed system libraries first. This also solves the security update issue. The bundled libs are only used as a last resort.

Regarding config files and /var. This is mainly aimed user applications. Would you install MySQL this way? Maybe to play with but NEVER as a server. This is perfect for apps like Gimp, k3b, OpenOffice, Firefox, etc. Config files can always be checked in two locations. A system /etc and a user ~/.foo.conf

Too apply this idea to the system level look at GoboLinux[http://www.gobolinux.org/] or GNU stow. Both use symlinks to map the individual dirs to a common heirarchy.

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).

It's a step backward

[Khazunga]

The Unix filesystem hierarchy has network maintenance taken into account. Having program 'bundles' may be great for a single workstation, but is hell for a network-wide system. The FHS explains this much better than I could, so please read the rationale there.

Personally, I see this like going back to the DOS days. Linux/BSD have been dealing with shared libs in pretty sane ways. Although rpm is sometimes a pain in the butt, Debian's package system and Gentoo's Portage prove that dealing with dependencies automatically is feasible and confortable.

And, anyhow, for special cases, you can always drop apps into /opt and get the equivalent of a bundle. Oracle does this, vmware does this, as there are countless other cases.

ROX

[An Audience of One]

ROX (RiscOS On X) which has a filer, window manager and a session manager uses Application Directories taken from Risc OS. This sounds very similar to Apple Application Bundles.

Installation is done by copying the directory, and the first time you run it, it will be compiled. You do have to run it from ROX-Filer for this to be supported (just double-click on the application directory), otherwise you have to run a script inside the directory.

Recently ROX has combined AppDirs with the Zero Install installation method, which uses a caching-remote filesystem. You can run things direct from the server they are distributed on using a virtual filesystem which will locally cache the files.

There are already a lot of applications written for this.

/etc is great

[rduke15]

While I can see the advantages of having every app isolated in it's own directory, I feel that one of the things I really like in Linux is to have all configuration in one, relatively small, pure text hierarchy: /etc.

I can grep it easily when I look for something, and easily edit the relevant file, which is usually well commented. I cannot grep the entire / tree. Well, I suppose I could, but I certainly don't want to.

For the rest, grouping all an applications's files together sounds attractive, but I would be happy enough if every app just clearly documented what it did at install time so it's easy to undo. (I don't believe much in "uninstall" programs/scripts, seeing how they (don't quite) work on Windows).