App Bundles

[Alberto Ruiz]

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 at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg