App Bundles

[Brian J. Tarricone]

On 08/26/2009 05:30 PM, Stephen Paul Weber wrote:
though I guess

>> it's already incompatible since Mac app bundles use the .icns format,
>> which I doubt gtk or qt support natively.
> 
> MacOS actually supports formats besides icns for the app icon.

Ah, nice, didn't know that.  Do they support SVG?  If not, icons would
look pretty ugly in the dock.  At least .icns allows several sizes in
one file.

>>> The arch string for a system is:
>>>
>>> `uname -s  | tr '[:upper:]' '[:lower:]'`-`uname -m`
>> This might be something you'd choose not to support, but: whether or not
>> you can run the app also depends on the C++ ABI in use, and possibly
>> other things.  There's a discussion somewhere in the archives for this
>> list about XDG_LIB_HOME that might be illuminating.
> 
> XDG_LIB_HOME? How would that differ from LD_LIBRARY_PATH?

XDG_LIB_HOME isn't intended as a generic search path for the system's
dynamic linker.  It's intended as a location to search for
user-installed plugin files (for example), and would be located
somewhere in the user's home directory.

It's not really relevant to your proposal, but the discussion that
occurred regarding canonical arch strings is.

>>> uname -m should be normalised (i\d86, x86 => i386.  x86_64 => amd64)
>> I'd agree to i386 normalisation, but x86_64 is the canonical arch name
>> (at least by GNU standards), so we should use that.  I'd imagine
>> nowadays there are as many (if not more) Intel x86_64 setups than AMD, even.
> 
> This convention was actually adapted directly from the convention for Debian
> package arch strings, and that is where the 'amd64' historical value came
> from.

Ah, ok.  I tend to think sticking with the GNU convention is "better,"
but I don't feel particularly strongly about it.  At least leaving it as
x86_64 means one fewer special case in the bundle generator and in SW
that handles launching bundles.

>>> The environment should be such that the current working directory is /
>> Probably should use $HOME, or even somewhere in the bundle itself.
> 
> Hmm, fair enough.  I think MacOS starts from /, but it's unlikely that apps
> depend on that.

I guess ideally most (GUI) apps shouldn't depend on the working
directory for much of anything, but I figure most apps launched via some
GUI mechanism on the desktop today probably end up with $HOME as $PWD,
so that would be "least surprising" from the app's point of view.

>> In general the problem with app bundles on an OS like Linux is that it's
>> difficult to be sure dependencies are available, and if they are, it's
>> hard to tell if they're compatible.
> 
> This problem is the same on all OSs.  It's just on linux we have a solution
> (package managers) and so we think of it as a much bigger problem.

To some extent, I suppose.  It's just that when you build an app in
Xcode on any Mac, assuming you've set the correct multi-arch options,
it'll run on any Mac that meets your minimum system version requirements.

If I build an app on my Gentoo system, it may well not run on my Ubuntu
or Fedora systems, even if all the dependencies are present, especially
if the other systems are a year or two old.

> App bundles would have to either contain their libraries (gross, but
> possible) or use one of the other manual-resolution techniques from the
> Windows world.

True.  You can still run into things like glibc versioning issues, but
if you limit your audience to, say... distros released in the past 3
years or so, it might work ok.

> I didn't really intend to specify how dependencies are handled, only the
> format for bundling.

Sure.  I'm just worried that a proposal like this wouldn't gain much use
without

>> That, plus the fact that the usage model for most Linux distros pushes
>> users to prefer installing apps via their package manager, tends to make
>> app authors hesitant to building or distributing Linux binaries at all.
>>  Instead they rely on distro package maintainers to pick up their app
>> and package it.  While this works decently well, there's often a lag,
>> especially for less popular apps.
> 
> Really?  While I prefer versions from package managers, I get binaries from
> websites not in package form all the time.  They're usually just a tar that
> you have to put in some specific place.  Sometimes they're relocateable,
> which is nice.

Perhaps I'm just used to having a package manager that has everything
including the kitchen sink, but I guess I don't do that so much anymore
(I do remember doing that a lot back when I used to run Red Hat).

Regardless, tarballs aren't very accessible to the mythical "average
user" -- especially if it's required that you unpack the tarball to a
specific place.  While I won't put words in your mouth with regard to
your goals, personally, I'd have as a goal of a bundle spec a user
experience model where a user can simply download and unpack a bundle
wherever he or she chooses, and double-click to run it, without even
having to know that the bundle is actually a directory that contains a
bunch of files.  I'd want the bundle option to be easier than the
package manager, not harder, and not even of the same difficultly.

>> Binary relocatability is also an issue based on hardcoded path names.
>> With XDG_CONFIG_DIRS and XDG_DATA_DIRS this is alleviated somewhat, but
>> there could still be issues with, say, private shared libraries shipped
>> in the bundle, whether the intention is to link with them at
>> compile/link time, or open with dlopen().
> 
> LD_LIBRARY_PATH is the equivalent of XDG_DATA_DIRS for shared libraries.
> Many people hate it because of performance issues in searching more than one
> place for libraries.

LD_LIBRARY_PATH isn't so useful since it rarely contains the entire
library search path, and is often empty.  On my system, /etc/ld.so.conf
contains 10 paths in it, and that usually doesn't include the default
/lib and /usr/lib (at least it need not include those).

My use case here is in app with plugins.  Say you install it to /usr,
and it installs and looks for plugins in /usr/lib/foo-app-1.0/plugins/.
 I think most apps like that today just hardcode
$(libdir)/foo-app-1.0/plugins/ and only search that (maybe with an
app-specific dir under $HOME).

So if the user goes and installs a plugin to
/usr/local/lib/foo-app-1.0/plugins/, it doesn't get found.  This sort of
thing is why I think something like XDG_LIB_DIRS might be useful... but
mainly as a sort of "dlopen() search path", not a runtime linker search
path.  Maybe a better name for it would be XDG_MODULE_DIRS or
XDG_PLUGIN_DIRS.

Anyway, back to how this relates to the bundle proposal: again I'm
looking at this from the perspective of the app author.  I don't want to
have to do special things to make my app work in a bundle since I'm just
used to being able to rely on my app being installed to a single
location in something resembling a FHS-compliant manner.  If we had
XDG_PLUGIN_DIRS, our bundle launcher could dynamically prepend a path
under our bundle directory to XDG_PLUGIN_DIRS before launching the
plugin executable.

It could also prepend a path to LD_LIBRARY_PATH to handle private
libraries inside the bundle that are actually dynamically linked, but,
as I've implied, I don't think LD_LIBRARY_PATH is suitable for the app's
own use to search for things at runtime.

>> These issues aren't intractable, but it would help uptake if they could
>> be solved or at least made easy to deal with in one place.  Also a
>> bundle generation tool would be needed... the idea being that you want
>> making a bundle to be a trivially easy step that requires very little
>> work for the app author.  While personally I think autopackage is/was a
>> cool project, it clearly has not gained the following its authors hoped.
>>  An app bundle spec is probably doomed to the same fate unless it's
>> dirt-simple to set up bundle creation.
> 
> I'm strongly considering a script that converts any *.deb to an app bundle.
> It would have to assume that the contents of said package are relocateable
> (no way around that), but assumedly this tool would be used by devs.  It
> would have a switch to resolve dependencies manually and include them, or
> not.

Well, I'm sure that would be useful, but that's narrowing your audience
quite a bit.  Ideally I'd want to see a tool that builds the app bundle
as a part of the normal make-based build process, and not have anything
to do with a particular Linux distro package manager.  So when I'm
getting ready to do a new release of my package, I basically just do
"make distcheck && make app-bundle", and I'm done.

> Indeed.  MacOS is the only OS that really has such a feature these days, but
> still, it's a good feature to have.

I think GNUStep supports some type of bundle, probably similar to what
MacOS supports.  Might want to look into that too.  IIRC, ROX also has
bundles, but I'm not familiar with how they work.

	-brian