Linked by David Adams on Fri 16th Jul 2010 19:43 UTC, submitted by broomfighter
Linux "The Portable Linux Apps project brings the ideal of "1 app, 1 file" to Linux. Applications are able to run on all major distributions irrespective of their packaging systems - everything the application needs to run is packaged up inside of it. There are no folders to extract, dependencies to install or commands to enter: "Just download, make executable, and run!"" A follow-up article describes how it works, and how to transform debian packages into AppImages. The packages don't include libraries, so the system won't need to update the same library in each individual app.
Thread beginning with comment 433839
To read all comments associated with this story, please click here.
Some observations on this topic:
by lubod on Sat 17th Jul 2010 10:12 UTC
Member since:

The whole discussion of:

"This is great, now all the dependencies (including libraries) are included in the .app directory!" VS. "This is horrible, now you have 17 versions of the same library and 17 times the bloat!"

seems like a fanatic flamewar like vi VS. emacs or Gnome VS. KDE to me imho.

Here is why.

Construct the "autopackage" or whatever you want to call it this way:

Upon being run the first time, it checks what major Linux branch you run (e.g. Debian based .deb, Redhat based .rpm, etc (LSB should help here, as lsb_release -icr outputs distro name, version, code name). Yes I realize that would encourage fewer distros with fewer unique package formats, and no I don't think this is all that bad. If you have a distro that doesn't fit, send the package developer info that says " my distro has library x in location y, or my distro has .deb packages but the libraries are in the fedora default locations, and voila, if they use your input instead of ignore you, the next revision of the autopackage WILL work for you too.

If any of its dependencies (libraries or whatever) aren't present in their default location (for that distro), maybe even pop up a question "where is this library in your system?" with a default answer already input by being piped from locate "name of file" or a hint for you to run this short command yourself and paste the result in the question dialog. Once successful, symbolic link to system supplied files. Done!

If it can't be found anywhere, warn that it is so, and offer a choice:

A) Please install this from your package manager (supplying names of debian/redhat packages that contain this as hints), or

B) automatically wget said library and place it in the .app directory, with a brief warning (with a never show this warning again checkbox/command line switch) that "using the downloaded/"standalone" dependency may mean that this app is outdated and insecure, even when the rest of you system is properly up to date/secure.

And of course a preference item inside the app (toggle switch) between 1) "use built in dependencies" (more likely to run first time) VS.
2) "use system files for dependencies" (more secure and up to date).

No bloat or duplication for anyone that can resolve dependencies now, AND no "I can't run this junk, its missing some obscure library (or I don't know why it won't run!)". Everyone is happy!

Yes the initial packaging is longer and more complex(but the complexity is so structured I'd be surprised if it can't be scripted away), but only the very first time! All updates, whether from version 3.0.1 to 3.02 or 1.0 to 5.6 only need the changed files, so now Delta packages start to become easier/more common, so now updating Open Office isn't a 200 Mb download, its 25 Mb! So much more sane in places with slow/metered/capped/too expensive connections! Exactly the kind of places where open source can shine!

Reply Score: 1