I do not completely agree that we need this, but here is a proposal for an alternative mechanism:
* The user downloads a .netpkg.sh-file, which is a POSIX shell-script, and runs it. * The .netpkg.sh declares the variable UUID and assigns it a predefined random UUID that identifies the package. * The .netpkg.sh runs `netpkg --install-dependencies $UUID` and gives it in stdin a list of package UUID:s. This is a distro-provided command that runs that distro:s package managers to install those packages. Package UUID:s are random identifiers for packages that can either be generated by the developer of that package or by some numbers authority. * The .netpkg.sh runs `exec netpkg-install "$0" "$@" || true` which causes to program package to be maintained by the distro's package manager if it has that capability, if it does not `netpkg-install` does not exist and the command is ignored. * The .netpkg.sh downloads binaries or source files. * The .netpkg.sh compiles the files it has downloaded. * The .netpkg.sh installs the package to ~/.local or to another location of the user's choosing. * The user gets tiered of the packages and runs `package.netpkg.sh --uninstall` which causes the .netpkg.sh to uninstall the package. So what does everyone have to do: * Distros may choose to implement `netpkg` and `netpkg-install`. If they choose not to implement `netpkg` they need to provide a default `netpkg` that is capable of downloading missing dependenies and install them it ~/.local (or other directory or the user's choosing.) * Developers need to assign random UUID:s to there packages. * Freedesktop or some other body need to maintain a list of UUID:s for packages that have not created their own UUID:s. * Developer may choose to write .netpkg.sh file. * User may choose to install netpkg if it is not preinstalled and can than download .netpkg.sh and run them to install packages. Drawbacks: * Does not support installing packages that are no longer distributed by the developer. * Requires Internet connectivity during the beginning of the installation process. On Mon, 8 Dec 2014 15:02:32 -0800 Thomas Kluyver <[email protected]> wrote: > This may be a pipe dream, but XDG is the best place I > know to propose something like this: > > We need a new mechanism for distributing end-user > applications on free desktop platforms. > > Traditionally, distro packaging is considered the right > way to distribute applications. However, I believe that > distro packaging is designed to distribute libraries, > frameworks and such tools for developers and sysadmins, > not end user applications. Specifically: > > * Distro packages are almost always out of date. Even > with 'quick' six month release cycles, the gap between > the developer making a release and users getting it is > measured in weeks or months, when we (application > developers) want it to be hours or days. > * More broadly, distros put a layer between developers > and users. That has some benefits, but with end user > applications we generally want to engage more directly > with the user, to present the image we choose and get > feedback directly. > * You need to provide different instructions for each > distro - like this download page for 0AD: > play0ad.com/download/linux/ > * If you want to package your application yourself, you > realistically need to deal with at least .deb and .rpm > package formats, and if you care enough about smaller > distributions, there are still more formats. LSB > attempted to declare RPM the standard, but that hasn't > really worked. > * On most distros, packages can only be installed as > root, so to get even some trivial game working, you have > to hand it the keys to the kingdom. > > As a result, on many application webpages, the download > button gives you a .tar.gz file - e.g. Firefox, Eclipse, > Pycharm and Zotero. That avoids all of the issues listed > above, but it can't add things to $PATH, install .desktop > files, set up automatic updates, and so on, unless the > application's own code completes its installation when > it's first run. And if users are as lazy as me, they end > up with applications 'installed' in their Downloads > folder, which doesn't seem quite right. > > Still other applications try to rely on language specific > packaging tools. My background is in Python, and I've > seen applications recommend you install them with pip. > Python packaging tools are pretty bad even for the things > they're supposed to do, and distributing applications is > not one of those things. > > So, I would like a mechanism whereby: > > 1. Developers can publish applications without going > through distro maintainers. This could either be > self-hosted installer files, or a centralised location > where you're free to claim a name (like PyPI, CPAN, etc.) > 2. When the user installs an application, it can set up > command line tools on $PATH and .desktop files to launch > the application from the GUI. 3. Applications can be > installed into ~/.local without giving them root > privileges 3.a For bonus points: capabilities based > security, because root is not the only thing we care > about: http://xkcd.com/1200/ 4. The installer should be > able to specify dependencies on system packages for any > relevant packaging systems, because the developer > shouldn't be forced to bundle dependencies any more than > they should be forced to unbundle them. 5. A user with an > application installed should be notified of updates, > without every application having to implement its own > update checker and downloader. 6. Ideally, all of this > should be an addition to a tarball, so sites can offer a > single .app.tar.gz file, and users without the installer > mechanism can extract the files and launch the > application manually. 7. This should, of course, be > distro and desktop independent. We definitely can't > afford to fragment it by GNOME vs. KDE, or Debian vs. Red > Hat. Applications should have *one* button to download > for Linux. > > I am working on an end-user application, and I will try > to build something like this and test it by distributing > that (glossing over 3a and probably skipping 5 for the > first iteration). Feedback, offers of help, and telling > me about similar things that already exist are all > welcome. > > Thanks, > Thomas _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
