App Bundles

[Stephen Paul Weber-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

In some contexts, app bundles (where all files for an application live in
some folder, like on MacOS) are useful.  I've been thinking recently about
an app bundle layout that is based on freedesktop specs and also not
gratutitously different from the MacOS layout.  I share it here because
someone might like the idea, or have an even better one.

An app bundle is any directory containing a Contents folder which contains
an app.desktop file.

The icon for the bundle is the icon for the desktop entry.  Icons should be
searched for first in Contents/Resources and then according to the rest of
the icon theme spec.

The arch string for a system is:

`uname -s  | tr '[:upper:]' '[:lower:]'`-`uname -m`

uname -m should be normalised (i\d86, x86 => i386.  x86_64 => amd64)

When executing the bundle, read the Exec line in the normal way, but behave
as though Contents/`arch string` were prepended to path.

That is:

Exec=firefox %U

Will first try:

Contents/linux-i386/firefox

on my system.

The environment should be such that the current working directory is / and
the program has been invoked using it's absolute path (such that dirname $0
becomes the absolute path to the program).

The primary executeable should be encouraged to prepend `dirname
$0`/../Resources to XDG_DATA_DIRS in order to find its data.

To make this app bundle compatible with MacOS, the following must be
performed:

ln -s darwin-i386 MacOS

The content of the Exec line with % codes stripped is CFBundleExecutable.
Icon and Name may optionally also be extracted.
This data put into Info.plist in the correct XML format.

- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKlbZAAAoJENEcKRHOUZzeJnQQAMmNkGGD2X6nibemSmAdCQqo
tg/nGp5c4+Z2Np4G0xY/6FTD5amV+JloJJdJ3r/cAkVuvau/fkaZDmw+eEgWzblp
R9YiyGwPbJRq5tAmROe9/yIXFos8HEFGSl9XNzpukQ4TvPGdv3wv9SxjuhQD7tha
d4fSz1NFdhyGoMUBCRiph4070RIZoP6AFrNEcyCoUqrooA2XK8z1A9MKpClKwnG1
pnPkPX7Y5C0wNb2V71u7W8/pRMSJTIP6y8/Tn1t4lyideaQeXmEMtM5Xa0BIY+u4
sjc6pD/+u1cyUjfb5l4praiGh3iO1NXo+aNJTn20zmUPR646n5oJpsytzCPD3HRH
lEYtXrRIYlEkXHdgNKqdK8B/Un6QezScEuLP/BgvLrRTZZyOrlG6TXqtwBIREY7e
ezTEutaLy2K+nw20C3HlD0J8hRlUf/zybxPLDW6v/fC+JeWnnaphYWKCXsTIpFWF
3iLov4ZoG/pUaOAB64+DGctLjK6ywx++HbR/XvDkZqzmAm04ktlhWSVakF4iI0H+
GBDlB8odE3aoctPRblf3Wk6ct219NNkzTfPvrIO3f1yxHYm+ouI1ggRQjyLJ8Dks
PhQqubUygyDB/qonTLg6J+KMLVOAY903TNvIUxoTzKDWCItfLi3QQK9BKNw6sJae
FVyMAZ/dZsu2Fl3cxjS5
=Tuq9
-----END PGP SIGNATURE-----
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone]

On 08/26/2009 03:25 PM, Stephen Paul Weber wrote:
> In some contexts, app bundles (where all files for an application live in
> some folder, like on MacOS) are useful.  I've been thinking recently about
> an app bundle layout that is based on freedesktop specs and also not
> gratutitously different from the MacOS layout.  I share it here because
> someone might like the idea, or have an even better one.

Cool!

> An app bundle is any directory containing a Contents folder which contains
> an app.desktop file.

This might be a bit too general.  Why not define a standard extension
(such as .app) for the directory name like MacOS X does?

> The icon for the bundle is the icon for the desktop entry.  Icons should be
> searched for first in Contents/Resources and then according to the rest of
> the icon theme spec.

I'd prefer to have an 'icons' subdir (or something) inside Resources
that has a directory structure that complies with the icon theme spec.
Of course that makes for another MacOS X incompatibility, though I guess
it's already incompatible since Mac app bundles use the .icns format,
which I doubt gtk or qt support natively.

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

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

> The environment should be such that the current working directory is /

Probably should use $HOME, or even somewhere in the bundle itself.

> the program has been invoked using it's absolute path (such that dirname $0
> becomes the absolute path to the program).

I like this -- greatly simplifies finding stuff included in the bundle,
regardless of what $PWD is (or ends up being changed to by the app).

> The primary executeable should be encouraged to prepend `dirname
> $0`/../Resources to XDG_DATA_DIRS in order to find its data.

Sure... assuming that the app will store its data in an app-specific
subdir of Resources/, this will also work for installs of the app in a
"normal" FHS-compliant manner.

> To make this app bundle compatible with MacOS, the following must be
> performed:
>
> ln -s darwin-i386 MacOS
>
> The content of the Exec line with % codes stripped is CFBundleExecutable.
> Icon and Name may optionally also be extracted.
> This data put into Info.plist in the correct XML format.

Presumably this would be done automatically by whatever tool is written
to build the bundle file.

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.

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.

But all of these things can be worked around to some extent.  There are
ways to build your app so that it makes use of lowest-common-denominator
features, and you can do things like build against the oldest version of
the gtk+ headers that you support.

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

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.

Of course there's also the other part of it: getting support into major
desktops.  You'll want to be able to display the app bundle directory as
an executable file in your file manager, and, for command-line users,
you'll want a simple bundle-open command or something.

Also someone should look at security issues: recently (and not so
recently) there have been security concerns raised over how .desktop
files are handled in file managers and on desktops.  I imagine similar
concerns would be raised about app bundles.

Anyway, I do think this is a worthwhile idea, and fills what I sometimes
think is a big hole in making Linux more mainstream-accessible: the
ability to download an app from the app author's website and run it as-is.

        -brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Stephen Paul Weber-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

> > An app bundle is any directory containing a Contents folder which contains
> > an app.desktop file.
>
> This might be a bit too general.  Why not define a standard extension
> (such as .app) for the directory name like MacOS X does?

That's an option, if people thing the above requirement is too loose.

> > The icon for the bundle is the icon for the desktop entry.  Icons should
> > be
> > searched for first in Contents/Resources and then according to the rest of
> > the icon theme spec.
>
> I'd prefer to have an 'icons' subdir (or something) inside Resources
> that has a directory structure that complies with the icon theme spec.
> Of course that makes for another MacOS X incompatibility, 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.
I think I agree about the 'icons' subdir.  The generated Info.plist could
then be made by a script that resolves the path inside Resources according
to spec and puts the whole relative path in (which I believe should work).

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

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

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

> > the program has been invoked using it's absolute path (such that dirname
> > $0
> > becomes the absolute path to the program).
>
> I like this -- greatly simplifies finding stuff included in the bundle,
> regardless of what $PWD is (or ends up being changed to by the app).

Yes.  That's basically how all discovering the location of stuff in the
bundle works on MacOS.

> > The primary executeable should be encouraged to prepend `dirname
> > $0`/../Resources to XDG_DATA_DIRS in order to find its data.
>
> Sure... assuming that the app will store its data in an app-specific
> subdir of Resources/, this will also work for installs of the app in a
> "normal" FHS-compliant manner.

Yes.

> > To make this app bundle compatible with MacOS, the following must be
> > performed:
> >
> > ln -s darwin-i386 MacOS
> >
> > The content of the Exec line with % codes stripped is CFBundleExecutable.
> > Icon and Name may optionally also be extracted.
> > This data put into Info.plist in the correct XML format.
>
> Presumably this would be done automatically by whatever tool is written
> to build the bundle file.

Yes.

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

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.

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

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

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

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

> Of course there's also the other part of it: getting support into major
> desktops.  You'll want to be able to display the app bundle directory as
> an executable file in your file manager, and, for command-line users,
> you'll want a simple bundle-open command or something.

I actually have the start of such a bundle-open command, but yes, the big
hurdle would be getting GNOME and KDE to support the format.

> Anyway, I do think this is a worthwhile idea, and fills what I sometimes
> think is a big hole in making Linux more mainstream-accessible: the
> ability to download an app from the app author's website and run it as-is.

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

- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKldO5AAoJENEcKRHOUZzexf0P/06S0+oA2C/1YIMPvrjfqvw6
x5QpevcizjwrQOEzlMEqiN8s0Y+qU7Uz4ZGOHmAzuIK7xPUaKKlhPAwaVafGNPma
BeR6OTMaMUXkEInDICf5saDalRj50AKREXjQnXh84RaJin45Jxf/odMAgfzX2tFh
Wa+5xz+TDAFvh29ARGvpOdIQH15aix8qIvhK0z8r84O4z+f6C0gD3ie+zjNORY6J
Jm/HQNE+BTykUtR+51Ofk05RNC9oLzTve1SW7QrB6vxM+H2oM2xLjcyoIQsje55x
i5joq1ggUSRbepFqu8iSn9g23y/6L60KqXmZY7qNu/X/fuaC66NCk0PY3JDT5t+7
WG/ljOkJSJmMGvvntze5/9+Zddk6FU/WMyflkB9EJn1r3GeL2f3Eww3Td4XR6vFs
V1gBfnlHjzfNYr8maZc12tBFKfZZ5Ngy4MqEBxmMejghXhEXoYayCKuOA3hbyIR+
ebgUK+d6bJpd/OxJtz/K4ZVt+bOwCFuHaXnc0yU0ZE19BKZ5YnTE8TvDNElHJaLq
4keZ63AzFziGu1+cXLKnYgm0e7HgphBqZKlxQZwvPR7dS9qhVHHZXTQX49b/EPyx
TLiN1ki5YZjdRWhDFREUF6Wdh4rgvMNHA6FB0QtcmlNLcAFRK6aRW+D0zOrQGNH8
O2dxJAz2ahwboc4RJFIX
=+LeL
-----END PGP SIGNATURE-----
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[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
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Graeme Gill]

Brian J. Tarricone wrote:

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

The distro model certainly doesn't work for everybody. Too often distro's
fiddle with the application and break the package. Since they don't/can't
test it, they don't notice the problem, and the author of the package then gets
a lot of the grief. The distro model doesn't work for commercial applications
either, discouraging many serious applications from supporting Linux. So
more support for independent application installation would certainly be a
good thing.

Graeme Gill.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[André GILLIBERT-2]

"Brian J. Tarricone" <bjt23@...> wrote:

> 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).
>
I don't see your point. When LD_LIBRARY_PATH is used, /etc/ld.so.conf isn't ignored.
When searching shared libraries, directories are searched in the following order:
1) Directories listed in the DT_RPATH tag contained in the executable file if it exists and DT_RUNPATH doesn't.
2) Directories in the LD_LIBRARY_PATH env var.
3) Directories listed in the ELF DT_RUNPATH tag if it exists.
4) /etc/ld.so.cache which is "compiled" by ldconfig from /etc/ld.so.conf
5) /lib and /usr/lib

Consequently, if an application wants to launch an app bundle and make it use its own shared libraries, it may add this path into the LD_LIBRARY_PATH env var.

Alternatively, the application may simply store a DT_RPATH tag in its executable file, containing the string $ORIGIN/lib (GNU ld feature).

IMO, the later is better as a fork/exec won't bring this dangerous LD_LIBRARY_PATH into child processes.
Just think about an application bundle, bundling its own "standard libraries", such as GLIBC, because it may depend on a specific version or because it's not always installed on all systems (e.g. libXt).
If this application forks/exec another program, the child process will get the bundled libraries rather than the distro libraries, which may cause stability (and security) issues if there are incompatibilities between the bundled library and the distro library.

With DT_RPATH, exec'ed programs won't get these libraries.

Moreover, it makes launching the bundled application easier, since it may be launched from the command line like that.

/path/to/bundle/bin/program

> My use case here is in app with plugins.
For plugins, applications should simply build a path based on their bundle path they get from argv[0] and call dlopen on their own.
IMO, env vars are dangerous for bundled applications, since they're inherited by child processes.
The bundled application may be an application launcher itself!

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

And how would an application recognize which plugins are compatible with itself in the mess of dirs you would get when chaining bundled applications with fork/exec.

Rule of the thumb:
1) If you want a setting to be inherited by exec'ed processes, use an env var.
2) If you don't want so, use a parameter (argv[0] being one of them).

So, the plugin dir should be pointed by a a parameter.
Since it should be a subdir of the bundled application dir and you've already defined a way to get this dir (argv[0]), the application has everything it needs.

--
André Gillibert


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[André Gillibert]

"Brian J. Tarricone" <bjt23@...> wrote:

> 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).
>
I don't see your point. When LD_LIBRARY_PATH is used, /etc/ld.so.conf isn't ignored.
When searching shared libraries, directories are searched in the following order:
1) Directories listed in the DT_RPATH tag contained in the executable file if it exists and DT_RUNPATH doesn't.
2) Directories in the LD_LIBRARY_PATH env var.
3) Directories listed in the ELF DT_RUNPATH tag if it exists.
4) /etc/ld.so.cache which is "compiled" by ldconfig from /etc/ld.so.conf
5) /lib and /usr/lib

Consequently, if an application wants to launch an app bundle and make it use its own shared libraries, it may add this path into the LD_LIBRARY_PATH env var.

Alternatively, the application may simply store a DT_RPATH tag in its executable file, containing the string $ORIGIN/lib (GNU ld feature).

IMO, the later is better as a fork/exec won't bring this dangerous LD_LIBRARY_PATH into child processes.
Just think about an application bundle, bundling its own "standard libraries", such as GLIBC, because it may depend on a specific version or because it's not always installed on all systems (e.g. libXt).
If this application forks/exec another program, the child process will get the bundled libraries rather than the distro libraries, which may cause stability (and security) issues if there are incompatibilities between the bundled library and the distro library.

With DT_RPATH, exec'ed programs won't get these libraries.

Moreover, it makes launching the bundled application easier, since it may be launched from the command line like that.

/path/to/bundle/bin/program

> My use case here is in app with plugins.
For plugins, applications should simply build a path based on their bundle path they get from argv[0] and call dlopen on their own.
IMO, env vars are dangerous for bundled applications, since they're inherited by child processes.
The bundled application may be an application launcher itself!

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

And how would an application recognize which plugins are compatible with itself in the mess of dirs you would get when chaining bundled applications with fork/exec.

Rule of the thumb:
1) If you want a setting to be inherited by exec'ed processes, use an env var.
2) If you don't want so, use a parameter (argv[0] being one of them).

So, the plugin dir should be pointed by a a parameter.
Since it should be a subdir of the bundled application dir and you've already defined a way to get this dir (argv[0]), the application has everything it needs.

--
André Gillibert


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone]

On 08/27/2009 02:19 AM, André Gillibert wrote:
> "Brian J. Tarricone" <bjt23@...> wrote:
>
>> 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).
>>
> I don't see your point.

I'm not talking about the runtime dynamic linker finding shared
libraries that were linked at compile time to the executable.  (Though,
admittedly, this is *another* problem we'd need to solve if we want to
allow bundles to include their own private copies of libraries.)

I'm talking about an application specifically enumerating files in
certain paths to look for shared objects (e.g. plugins) to dlopen().

Currently most applications that use plugins will require that plugins
are installed to the same location that the app is installed.  Some do
things like have environment variables (e.g., GTK_PATH) that allow you
to modify the search path, but this is non-standard and would need to be
set separately for every app that supports it.  Apps that don't support
it are left out in the cold, or would need to be patched to add their
own non-standard env var.

Take for example Audacious, the music player.  It looks for audio output
plugins in $libdir/audacious/Output, or, in my case,
/usr/lib64/audacious/Output.  It looks there because that particular
path is hard-coded into the audacious binary.  It does not, for example,
look in /lib64/audacious/Output, or in /usr/local/lib/audacious/Output,
or, perhaps more usefully, in
/opt/plugin-i-want-to-test/lib/audacious/Output.  I cannot change this
path without recompiling.  I cannot make it look in multiple places[1].

Let's take an analogous example that doesn't involve libraries.  When my
session manager starts up, it runs autostart applications.  It does not
have a hard-coded place (or set of places) to look[2].  It looks in a
colon-separated list of directories in the XDG_CONFIG_DIRS environment
variable, and in XDG_CONFIG_HOME.  I can tell it to search whatever
system (or non-system) directories I wish.  Since I have Xfce installed
to /opt/xfce4-git, I add /opt/xfce4-git/etc/xdg to XDG_CONFIG_DIRS and
everything works just fine.

Now let's apply this to our bundle (obviously this is all hypothetical).
 Before launching the bundle, my file manager will look at
XDG_CONFIG_DIRS, and add the path to the bundle's Resources
subdirectory.  The application in that bundle doesn't need to know a
thing about bundles.  It just follows the XDG basedir spec and happily
finds its files.

But what about plugins?  In order to load its plugins, it needs to know
where they are.  They're in some subdirectory of the bundle, say
Resources/lib/plugins.  But how does it find them?  Well, with how
things are currently done, it can't.  At least, not without
modifications to how it's built, and how it resolves paths.

>> My use case here is in app with plugins.
> For plugins, applications should simply build a path based on their bundle path they get from argv[0] and call dlopen on their own.

Unacceptable.  This means that every application that uses plugins will
need to be aware of whether or not it's in a bundle, or at least will
need to be aware of a dynamic prefix.  We already have the ability to do
this -- see autopackage's relocatable stuff (which don't even require
autopackage).  But who actually uses it?  I can think of very few offhand.

If people are serious about this bundle thing, it needs to work without
needing major modifications to applications.  Or, rather, it needs to
work within a framework not specific to the bundle.  XDG_CONFIG_DIRS and
XDG_DATA_DIRS clearly buy me several advantages as an app author (and
the apps's user) that have nothing to do with making relocatable
bundles.  Something like XDG_PLUGIN_DIRS would as well, and it would be
a benefit to all applications, whether packaged as a bundle, or packaged
in the 'traditional' manner.

> IMO, env vars are dangerous for bundled applications, since they're inherited by child processes.
> The bundled application may be an application launcher itself!
>
>> 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.
>
> And how would an application recognize which plugins are compatible with itself in the mess of dirs you would get when chaining bundled applications with fork/exec.

If the app doesn't already have a means to recognize plugins that aren't
compatible (via some internal versioning system), then it's broken.
Look at gstreamer, for example, which uses a versioned directory name
which changes when the plugin interface breaks ABI.  Xfce's old
configuration system used an ABI version number embedded in the .so that
would get checked by the configuration manager after dlopen()ing it.

If an app is installing its plugin files directly into a shared
namespace (e.g. /usr/lib instead of /usr/lib/foo-app), then it deserves
to break anyway.

If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and
Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there
can never be any conflict, even if both of them are set up as bundles
and one launches the other with their "private" bundle path in
XDG_PLUGIN_DIRS.

> Rule of the thumb:
> 1) If you want a setting to be inherited by exec'ed processes, use an env var.
> 2) If you don't want so, use a parameter (argv[0] being one of them).

That's nice in theory, but when you're trying to convince hundreds of
app authors to do extra work to support your pet packaging format that
no one uses, it sounds like a hard sell.

In this case I'm suggesting that it *doesn't matter* if XDG_PLUGIN_DIRS
has extraneous entries in it.  If apps are written properly, there's
just no problem.  If they're not written properly, then that's a bug,
and they'll probably have issues when installed in the traditional
manner too.

> So, the plugin dir should be pointed by a a parameter.
> Since it should be a subdir of the bundled application dir and you've already defined a way to get this dir (argv[0]), the application has everything it needs.

No, it doesn't have everything it needs.  It may have all the
*information* it needs, but it doesn't know to do anything with it
without extra work.  Even if that extra work is minimal, you still have
to convince the app author that doing that work is worthwhile.  Or you
have to go out and provide patches for hundreds of applications, and
shepherd these patches through each app's submission and review process.

Listen... I personally (for my own use) don't care if we have a bundle
system or not.  But I think it could be immensely useful for users who
don't want to touch a command line and just want to quickly try out a
piece of software that their distro hasn't packaged.  It's also a much
more logical and friendly flow to see something on a website, and
download it from that website and try it immediately and simply.

So please understand that my perspective here is from an application
author and desktop environment maintainer.  I'd be happy to write a
bundle launcher implementation for Thunar and xfdesktop, or have them
use one that could be provided in GIO/GVfs.  The launcher implementation
side is a small target: get Nautilus and Konqueror to implement bundle
launchers and you could conceivably say you're done on that side.

But then you need actual bundles to launch, and unless you make it dirt
simple and compelling for app authors to make their apps relocatable, it
just isn't going to happen.[3]  Don't take my word for it: look to
autopackage's relocation efforts and how well that took off.

        -brian

[1] Well, it probably also has a per-user plugin directory in $HOME, but
that's also hard-coded and doesn't address the problem here.

[2] Of course it has a fallback default search path if XDG_CONFIG_DIRS
isn't defined, but... not really the point.

[3] The holy grail would be... "drop this autoconf macro in $top_srcdir,
add FOO_CREATE_BUNDLE to configure.ac, run autoreconf, and type 'make
bundle'."  Bonus points if we can remove the first step in that.

Yes, I'm aware that something like XDG_PLUGIN_DIRS would require app
changes to support.  But my thesis here is that XDG_PLUGIN_DIRS is
*generically* useful, and something that app authors would likely adopt
without a bundle spec, similarly to how app authors adopted
XDG_CONFIG_DIRS and XDG_DATA_DIRS.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[André Gillibert]

"Brian J. Tarricone" <bjt23@...> wrote:

> If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and
> Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there
> can never be any conflict, even if both of them are set up as bundles
> and one launches the other with their "private" bundle path in
> XDG_PLUGIN_DIRS.

Okay, that solves the issue. I thought the application would search its plugins in "$XDG_PLUGIN_DIRS/" which would have made all plugins of all applications stored in the same directory.

> No, it doesn't have everything it needs.  It may have all the
> *information* it needs, but it doesn't know to do anything with it
> without extra work.  Even if that extra work is minimal, you still have
> to convince the app author that doing that work is worthwhile.

Since most current applications do use absolute paths, if you don't want to touch application's souce code, then, you've to run them in a chroot'ed environment. There's no other way.

What's different with XDG_PLUGIN_DIRS! You've to convince the author to compute the path from this env var! How is that easier than doing it from argv[0] ?
Moreover, from your first post I assumed you expected applications to use argv[0] to find their own data files. So, why treating data and plugin files differently?

Ok, now I see a compelling reason:
XDG_PLUGIN_DIRS would be to let people use plugins not bundled with the application in addition to plugins bundled with the application, the former being kept in a /usr/share/plugins/appname directory.

In short, the following approach seems good.
1) Bundled applications would be directories containing a standard file system hierarchy with ./usr/lib ./usr/bin, ./usr/share, etc.
2) When launched without path prefix, the application would assume the "base directory" is /, otherwise it would be the directory prefix with the final usr/bin truncated.
To make that easy, a simple library providing a getBaseDirectory() function would be created.
3) When loading a data file, it would use this base directory as prefix.
4) When loading a plugin, the application would use a getPluginDirectories() enumerator function and its app-name suffix.
I see two possible implementations to this function:
1. Simply list XDG_PLUGIN_DIRS directories, requiring desktop environment to add the base directory to this plugin dir when launching the bundled application.
2. Or, list XDG_PLUGIN_DIRS directories plus getBaseDirectory()/usr/plugins.
I think the later is better, as both implementations have the same application interface, but the former has a more complex interface to the desktop.

This simple command:
cp -r /path/to/bundle/* /
Would install the bundle application.

Launching the application, bundled or unbundled would be as simple as giving its full path on the command line. When installed, you could also type its name without prefix.
e.g.

/path/to/bundle/usr/bin/nice_app
/usr/bin/nice_app (if it has been copied to /)
nice_app (if it has been copied to /)

Would all launch the application correctly!

To make bundle applications nicer, as you suggested, a desktop file should be provided.
Where?
Maybe in ./usr/share/applications/nice_app_name.desktop
But that would prevent the application to have more than one desktop file...
Or maybe simply ./app.desktop as you suggested, but that would make installing the bundle a bit more complex than cp -r.
There may be some better way.

--
André Gillibert.


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Brian J. Tarricone]

On 08/27/2009 06:12 AM, André Gillibert wrote:
> "Brian J. Tarricone" <bjt23@...> wrote:
>
>> If Foo-app looks for its plugins in $XDG_PLUGIN_DIRS/foo-app, and
>> Bar-app looks for its plugins in $XDG_PLUGIN_DIRS/bar-app, then there
>> can never be any conflict, even if both of them are set up as bundles
>> and one launches the other with their "private" bundle path in
>> XDG_PLUGIN_DIRS.
>
> Okay, that solves the issue. I thought the application would search its plugins in "$XDG_PLUGIN_DIRS/" which would have made all plugins of all applications stored in the same directory.

No, no, I'm still thinking of something very similar to
XDG_CONFIG_DIRS/XDG_DATA_DIRS.  The spec requires that subdirectories of
those directories be used.  So while the default XDG_DATA_DIRS is
/usr/local/share:/usr/share, the default XDG_PLUGIN_DIRS would probably
be /usr/local/lib:/usr/lib.

>> No, it doesn't have everything it needs.  It may have all the
>> *information* it needs, but it doesn't know to do anything with it
>> without extra work.  Even if that extra work is minimal, you still have
>> to convince the app author that doing that work is worthwhile.
>
> Since most current applications do use absolute paths, if you don't want to touch application's souce code, then, you've to run them in a chroot'ed environment. There's no other way.
>
> What's different with XDG_PLUGIN_DIRS! You've to convince the author to compute the path from this env var! How is that easier than doing it from argv[0] ?
> Moreover, from your first post I assumed you expected applications to use argv[0] to find their own data files. So, why treating data and plugin files differently?
>
> Ok, now I see a compelling reason:
> XDG_PLUGIN_DIRS would be to let people use plugins not bundled with the application in addition to plugins bundled with the application, the former being kept in a /usr/share/plugins/appname directory.

Right.  My idea here is that yes, of course apps would need to change
code to use XDG_PLUGIN_DIRS, just like they had to for XDG_CONFIG_DIRS
and XDG_DATA_DIRS.  But the difference from using argv0 is that you get
other benefits with XDG_PLUGIN_DIRS, so you're not trying to convince
app authors to support something special *just* for bundle support.

> In short, the following approach seems good.
> 1) Bundled applications would be directories containing a standard file system hierarchy with ./usr/lib ./usr/bin, ./usr/share, etc.

Eh, not sure we really need this, but it would make building bundles a
lot easier.  Stephen's original idea was to make our bundle spec look
like MacOS X's bundle spec to avoid gratuitous incompatibilities, which
is a goal I agree with.

> 2) When launched without path prefix, the application would assume the "base directory" is /, otherwise it would be the directory prefix with the final usr/bin truncated.

Well, I think to be safe we should require that the bundle is *always*
launched with an absolute path.  This isn't hard to do, though it does
mean that you can't correctly run the app just by finding the binary in
the bundle and running it.

A bundle launcher would need to take care to do things like:

1. Set up XDG_CONFIG_DIRS, XDG_DATA_DIRS, and XDG_PLUGIN_DIRS.
2. Find the absolute path of the app inside the bundle and launch it.

> To make that easy, a simple library providing a getBaseDirectory() function would be created.

Well, a new library isn't needed.  Glib and libxfce4util already has
functions to determine the other XDG basedirs, and I assume Qt has
something similar.  We'd just add XDG_PLUGIN_DIRS to that.

> 3) When loading a data file, it would use this base directory as prefix.

No, it would use the same method it does now that follows the XDG
basedir spec.

> 4) When loading a plugin, the application would use a getPluginDirectories() enumerator function and its app-name suffix.
> I see two possible implementations to this function:
> 1. Simply list XDG_PLUGIN_DIRS directories, requiring desktop environment to add the base directory to this plugin dir when launching the bundled application.
> 2. Or, list XDG_PLUGIN_DIRS directories plus getBaseDirectory()/usr/plugins.
> I think the later is better, as both implementations have the same application interface, but the former has a more complex interface to the desktop.

Ok, now I'm confused -- what is this "base directory" and why is it
necessary?

> This simple command:
> cp -r /path/to/bundle/* /
> Would install the bundle application.

Well, more like

cp -r /path/to/bundle.app /wherever/the/user/wants

> Launching the application, bundled or unbundled would be as simple as giving its full path on the command line. When installed, you could also type its name without prefix.
> e.g.
>
> /path/to/bundle/usr/bin/nice_app
> /usr/bin/nice_app (if it has been copied to /)
> nice_app (if it has been copied to /)

This kinda defeats one of the purposes of the bundle: to hide all the
details of how it works from the user, and just present it as a single
unified package that you can run.  Bundles aren't primarily intended for
users who use the command line; they're intended for users who just want
to download an app from a website and double click on it to run it,
without needing to do any other setup.  (Not saying command-line users
*can't* use bundles, which is why we'd write a simple bundle-open
command that does the same things that a file manager or desktop manager
would do when the user double clicks the bundle.)

> To make bundle applications nicer, as you suggested, a desktop file should be provided.
> Where?

I don't think the intention here is to install .desktop files outside
the bundle.  There isn't really a way to do this because bundles are
relocatable: if the user moves the bundle, then the .desktop file
becomes invalid.

> Maybe in ./usr/share/applications/nice_app_name.desktop
> But that would prevent the application to have more than one desktop file...
> Or maybe simply ./app.desktop as you suggested, but that would make installing the bundle a bit more complex than cp -r.
> There may be some better way.

Well, as Stephen's original proposal stated, there will be a .desktop
file inside the bundle that actually determines the program (inside the
bundle) that gets launched, and also provides a display name, icon, etc.
 The desktop's system menu won't know about this .desktop file, and I
think that's fine.  These are intended to be transient apps that aren't
necessarily permanently installed.  We might want to consider system
menu integration at some point, but I don't think that's necessary to
get the base idea working.

        -brian
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Alberto Ruiz-5]

Brian J. Tarricone wrote:

> On 08/26/2009 03:25 PM, Stephen Paul Weber wrote:
>  
>> In some contexts, app bundles (where all files for an application live in
>> some folder, like on MacOS) are useful.  I've been thinking recently about
>> an app bundle layout that is based on freedesktop specs and also not
>> gratutitously different from the MacOS layout.  I share it here because
>> someone might like the idea, or have an even better one.
>>    
>
> Cool!
>
>  
>> An app bundle is any directory containing a Contents folder which contains
>> an app.desktop file.
>>    
>
> This might be a bit too general.  Why not define a standard extension
> (such as .app) for the directory name like MacOS X does?
>  

There is also a performance penalty, if you don't use an extension on
the folter, a file browser will need to poke every single directory to
check if there's a app.desktop file inside. Whereas, with a folder name
with a extension, like folder.app, we can have a special mimetype to
handel this. Once that is detected, *.desktop files would be detected.
>> The icon for the bundle is the icon for the desktop entry.  Icons should be
>> searched for first in Contents/Resources and then according to the rest of
>> the icon theme spec.
>>    
Why don't we stick to XDG data dirs spec inside of the bundle and we
treat it as an extended .local/ ? having share/icons for icons and that
sort of stuff.
> I'd prefer to have an 'icons' subdir (or something) inside Resources
> that has a directory structure that complies with the icon theme spec.
> Of course that makes for another MacOS X incompatibility, though I guess
> it's already incompatible since Mac app bundles use the .icns format,
> which I doubt gtk or qt support natively.
>  
Heh, exactly.

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

Yeah, things can gete very hairy. On the other hand, people should
bundle as many libs as they should to get their app to run across systems.
> I like this -- greatly simplifies finding stuff included in the bundle,
> regardless of what $PWD is (or ends up being changed to by the app).
>  
Agree.

>> The primary executeable should be encouraged to prepend `dirname
>> $0`/../Resources to XDG_DATA_DIRS in order to find its data.
>>    
>
> Sure... assuming that the app will store its data in an app-specific
> subdir of Resources/, this will also work for installs of the app in a
> "normal" FHS-compliant manner.
>
>  
>> To make this app bundle compatible with MacOS, the following must be
>> performed:
>>
>> ln -s darwin-i386 MacOS
>>
>> The content of the Exec line with % codes stripped is CFBundleExecutable.
>> Icon and Name may optionally also be extracted.
>> This data put into Info.plist in the correct XML format.
>>    
>
>  

I don't think we should make the budle compatible with MacOS to be
honest, I mean, we have plenty of XDG standards that covers most of the
stuff already and I think we should reuse them.

> Presumably this would be done automatically by whatever tool is written
> to build the bundle file.
>
> 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.
>
> 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.
>
> But all of these things can be worked around to some extent.  There are
> ways to build your app so that it makes use of lowest-common-denominator
> features, and you can do things like build against the oldest version of
> the gtk+ headers that you support.
>
> 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().
>  

That's not an issue as long as there is a .app launcher that takes care
of the $0 thingie.

In Windows systems, there's a call to get the path of the binary being
executed, this is what Gtk+ uses to allow itself to be relocatable on
Windows systems IIRC. We could have an libxdg-bundle with facilities for
this kind of stuff.

> 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.
>
> Of course there's also the other part of it: getting support into major
> desktops.  You'll want to be able to display the app bundle directory as
> an executable file in your file manager, and, for command-line users,
> you'll want a simple bundle-open command or something.
>  

I've been discussing this with Alexander Larssonn and some KDE guys,
Alex is all for the idea (he's the Nautilus maintainer), and I already
have some patches to enable Gtk+ to have subclases of the inode/folder
MIME type, I think both desktop would adopt something like this as long
as a sane standard is proposed here.

> Also someone should look at security issues: recently (and not so
> recently) there have been security concerns raised over how .desktop
> files are handled in file managers and on desktops.  I imagine similar
> concerns would be raised about app bundles.
>  
I don't think there's a difference between the normal .desktop and the
bundles in this regard, so it doesn't make the problem worse.

> Anyway, I do think this is a worthwhile idea, and fills what I sometimes
> think is a big hole in making Linux more mainstream-accessible: the
> ability to download an app from the app author's website and run it as-is.
>
> -brian
> _______________________________________________
> xdg mailing list
> xdg@...
> http://lists.freedesktop.org/mailman/listinfo/xdg
>  

_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Alberto Ruiz-5]

Stephen Paul Weber wrote:

> 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.
>
We can make use of PackageKit to solve these issues. The .desktop file
could have options like X-Bundle-Assumes = gtk2, libfoo and PackageKit
could solve the issue afterwards :-)

> 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.
>
> I didn't really intend to specify how dependencies are handled, only the
> format for bundling.
>
> > 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.

Exactly, for example NetBeans works this way, and gets installed in the
home directory, deleting it is a matter of running a script. or deleting
its container folder.

>
> > 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.
>
> > 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.
>
> > Of course there's also the other part of it: getting support into major
> > desktops.  You'll want to be able to display the app bundle directory as
> > an executable file in your file manager, and, for command-line users,
> > you'll want a simple bundle-open command or something.
>
> I actually have the start of such a bundle-open command, but yes, the big
> hurdle would be getting GNOME and KDE to support the format.

On the GNOME side, we're open to it, and for the conversations I had
with KDE people, I think they would be open to the idea as well (another
issue is who writes the patches, but I'm pretty sure we can manage), so
don't let that stop you ;-)
> > Anyway, I do think this is a worthwhile idea, and fills what I sometimes
> > think is a big hole in making Linux more mainstream-accessible: the
> > ability to download an app from the app author's website and run it
> as-is.
>
> Indeed.  MacOS is the only OS that really has such a feature these
> days, but
> still, it's a good feature to have.
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg


_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Stephen Paul Weber-3]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Somebody claiming to be Alberto Ruiz wrote:
> Stephen Paul Weber wrote:
>
> > 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.
> >
> We can make use of PackageKit to solve these issues. The .desktop file
> could have options like X-Bundle-Assumes = gtk2, libfoo and PackageKit
> could solve the issue afterwards :-)

Sure, that's one solution.

> > I actually have the start of such a bundle-open command, but yes, the big
> > hurdle would be getting GNOME and KDE to support the format.
> On the GNOME side, we're open to it, and for the conversations I had
> with KDE people, I think they would be open to the idea as well (another
> issue is who writes the patches, but I'm pretty sure we can manage), so
> don't let that stop you ;-)

Cool.

On the app dev side, I've written a first pass at a shell script that can be
run from inside a project to build an app bundle.

It assume make is being used, that there is a make install rule, and that
the make install rule properly handles  make prefix=blah/blah install

http://pastie.org/597905

It will generate `basename `pwd``.app in the current directory, with the
correct layout, and a wrapper script to set up the environment.

I have tested it on my patched version of Hedgewars (patched to use
XDG_DATA_DIRS and PATH for relocation) and it's worked marvelously.

Using a wrapper script to set up the env has many benefits.  It remains
compatible with MacOS (which does not set the env vars we're interested in)
and also means that you can easily invoke the script from the command line
(if you invoke it with its full path).  Also, app devs may wish to have a
slightly different env, and could therefore create their own wrapper script
if they desired.

- --
Stephen Paul Weber, @singpolyma
See <http://singpolyma.net> for how I prefer to be contacted
edition right joseph
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)

iQIcBAEBCAAGBQJKmAdqAAoJENEcKRHOUZzeI1QQALi/fw4CUxuqlcWcR0PW/lON
n3XKui4OQgedkCFLj2MpYOrmXonV8IlvCJguJvsvoBgvdGMdJAySWA77ZTWILTa2
I6qQQ78FUJyMn3WZxHQpQNiUD+NM4RSRCiVwZnHQlhnzAZbOvizgrueKyVph/tgq
dq7FO9XbWSLRkSzcoFTz6D8Ux2biwsd4BddDOEz+vEwfcYrO7W4JBCZWR3d1HnsF
U3Y4GnHTP7ozA/EPMRMLtriUvBxY/jsUJUOKM4uuX24wPf6Thnyb3aidpFdIPxJp
EGbyqa3nVdJwjUrTG6Iv5V//Uyahp/meQrlR3EwiYM/JyuJdxChTNtT4UtqvH+yD
Ua3XXx4U7DVRNJ9Eq9IGxtGJMfTdVooP8iplt+mCgLMMZgAwhLaSw2Mom7tc3gQh
Fzc96mIIm1VpXiZMsWj4i+bBGfWYkoeZYiU5I7hC8BXKForxgRevOT8fihGy6pqm
TfBstT2u/RnU4OKuHSohZz7bAHvMOmvSmO+W5M1SEQ7gixW0SDADz0Kd/hF23Br1
A8Ql9vVF4wQ2NElWhRLiq7uD+I7hSf9w8AViA3m+bP/ScK1rH7876pc1qnpb7rJt
Je/ZiWX4SAFfTuOtovbd4sg+Nimr3beR7hhMV2PDocumtw4BbVH/X3g53DNG1ZhE
YLQZdV04RUEjUVWgqyjh
=q94g
-----END PGP SIGNATURE-----
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg

[Stephen Watson]

Stephen Paul Weber <singpolyma@...> wrote:

> In some contexts, app bundles (where all files for an application live in
> some folder, like on MacOS) are useful.  I've been thinking recently about
> an app bundle layout that is based on freedesktop specs and also not
> gratutitously different from the MacOS layout.  I share it here because
> someone might like the idea, or have an even better one.

ROX has had Application Directories for years (based on RISC OS rather than
MacOS):

http://roscidus.com/desktop/AppDirs

--
Stephen Watson     http://www.kerofin.demon.co.uk/

Stranded here on planet earth / It's not much but it could be worse
_______________________________________________
xdg mailing list
xdg@...
http://lists.freedesktop.org/mailman/listinfo/xdg