Free desktop application distribution and installation

[Mattias Andrée]

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 <thomas at kluyver.me.uk> 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