Free desktop application distribution and installation

[Mattias Andrée]

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 <maandree at member.fsf.org> 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 <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
> 
> _______________________________________________
> xdg mailing list
> xdg at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/xdg