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