Free desktop application distribution and installation

[Thomas Kluyver]

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
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 decides the UUIDs? My first reaction is that
it will introduce more complexity. But I will re-read your message and
think through it some more.

Thanks,
Thomas
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/xdg/attachments/20141208/d0bcf686/attachment.html>