Free desktop application distribution and installation

[Mattias Andrée]

On Mon, 8 Dec 2014 17:54:09 -0800
Thomas Kluyver <thomas at kluyver.me.uk> wrote:

> Thanks Matthias & Mattias for your comments,
> 
> I will certainly look into Limba some more - I don't want
> to proliferate too many solutions if other people are
> working on this. From reading your blog post, my initial
> concern is that having a duplicate dependency system is
> too complex. My idea is that these application packages
> are only consumers of the system dependency management,
> and that only for sufficiently stable packages (like
> PyQt4). If the developer wants to bundle things, they
> just include the relevant files in their package, without
> telling the package system about them at all.
> 
> On 8 December 2014 at 15:38, Matthias Klumpp
> <matthias at tenstral.net> wrote:
> >> 3. Applications can be installed into ~/.local without
> >> giving them root privileges
> 
> > This actually has some security implications, e.g. a
> > malicious software can taint the other applications and
> > use them to hide itself. It also leads to some kind of
> > annarchy on one system, where different users are
> > running different software versions (and combinations
> > of them).
> >
> 
> Sure, it's a long way from perfect security against
> malicious applications. But it's a very easy step to
> take, and giving an application everything apart from
> root permissions is still better than giving it
> everything including root, so it's better than
> installing .deb/.rpm packages. 3a was my goal to improve
> security, but that's orders of magnitude more complex.
> 
> 
> > > 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.
> >
> > Why should they want to do that? This would not only
> > have all problems described in 3., but also have other
> > technical difficulties. E.g. you have version 1.0 of
> > application X which creates some configuration in your
> > home directory. Then you decide to "test" version 2.0
> > that way, which migrates your configuration to a higher
> > version. Then you decide to switch back to 1.0, or
> > simply launch 1.0 because you forgot about the local
> > copy. Version 1.0 can't read 2.0 configuration or in
> > the worst case might even corrupt it, and then you have
> > new trouble.
> >
> 
> I'm not quite sure about the link between that point and
> upgrading/downgrading config.
> 
> This is my attempt to address the obvious catch 22 here:
> why would users install the package installer tool if
> apps don't use it, and why would apps use that packaging
> format if users can't install it? My solution is that the
> packaging format is usable even without having the
> installer tool. All the applications that currently offer
> Linux downloads as a tarball could offer .app.tar.gz
> tarballs. If the user doesn't have the installer, they
> just keep using it like a regular tarball, but if they
> do, it opens in the installer, and shortcuts and
> dependencies are automatically installed for the user.
> 
> This may sound trivial, but I think it's actually very
> important. Users don't go looking for how to install
> applications, they look for *applications*, and assume
> the applications will tell them the best way to install
> that. If one or two applications offer 0install or Limba
> packages as an alternative, it's not worth the user's
> time to go and research that system, get it set up and
> then use it to install the application. You need a
> critical mass of applications to make the system a
> de-facto standard so users and distros will pay attention
> to it. Extending the lowest-common-denominator standard
> of tarballs is one way to get there.
> 
> If you'll excuse the cynicism, there may also be benefits
> to constraining the imagination of people building
> packaging systems. As an application developer, I have
> something cool working on my computer, and now I want to
> make it easy for other people to use it. When I go and
> read about making a 0install package, it says I should
> read the page about important concepts first. That page
> is full of sentences like: "When you launch a program
> (like Edit) 0install looks up the feed files of the
> interface and chooses an implementation of the interface
> and the interfaces it depends on according to the policy
> settings (e.g. preferring "stable" or "testing"
> implementations)." And my heart sinks. That sounds like a
> bunch of new stuff I need to learn about. What I want to
> see is more like: "make a tarball, however you want, with
> a couple of extra files in this and that fixed location,
> in the format described here..."
> 
> Mattias:
> 
> I'm not quite clear about what exactly your proposal is
> aiming at. I think you've identified differences in
> package naming among distros as a central concern, and
> the system of UUIDs is designed to overcome that. I don't

It is not entirely about difference in naming, it is more
about potential collisions and not requiring a central
registry. But package names would work too.

> think that's a big problem; as an application developer,
> maintaining a list of rpm dependencies and a list of deb
> dependencies is not especially hard. Also, there's
> disagreement over what consitutes a package - for
> instance, Riverbank releases PyQt as one big package, but
> Debian splits it into several smaller packages. Who

Here a package would be the .netpkg.sh, but if I distro
choose split it up yet would need a metapackage.

> decides the UUIDs? My first reaction is that it will

`cat /proc/sys/kernel/random/uuid` or `uuidgen` decides.
When you create a program/library you generate a UUID
and publish it. If you depend on a package that does
not have one, and whose maintainer is unwilling to
create one, you would have a central registry create
one. Ideally that registry would also have a lookup
table from UUID:s to .netpkg.sh-files dependencies
can be automatically installed even if they are missing
in your distro.

> introduce more complexity. But I will re-read your

The goal was to make it as simple as possible, but
perhaps there is a simpler way than UUID:s.

> message and think through it some more.
> 
> Thanks,
> Thomas