I have started on a project to demonstrate how it would look (not a serious implementation):
https://github.com/maandree/inetpkg On Tue, 9 Dec 2014 00:47:29 +0100 Mattias Andrée <[email protected]> wrote: > 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
