Free desktop application distribution and installation

[Matthias Klumpp]

2014-12-09 2:54 GMT+01:00 Thomas Kluyver <thomas at kluyver.me.uk>:
> Thanks Matthias & Mattias for your comments,
> [...]
>> 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 means without installation those tarballs are of no value to the
user, OR they contain a lot of bundled dependencies, which defeats
your point of pulling stuff from the distribution repositories.

> 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.

That's one way to see it - the IMHO better approach is to integrate
the installation solution seamlessly and make it a desired choice for
distributing applications. It's hard, but it is certainly possible (I
have some plans for that once Limba looses its experimental status).

> 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..."

Did you take a look at how to create a Limba package? ;-) The easiest
way with almost zero extra work is actually the Lennart-solution, but
that is also the least flexible one in terms of dependency-sharing
(and it also has a few other properties which I don't like much for
general-purpose application distribution).

> 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.

Oho, you would be suprised! It is actually *very* hard and a complex
task to perform for an upstream project author. It also limits a
software to a set of distributions.
The Listaller project, which uses the distribution package manager as
dependency source, did exactly that, and the code performing
dependency-matches and ensuring everything stays sane across
distributions was actually very complex, and the upstream projects
*still* had to put work into Listaller packages to tune their
dependencies.
Last summer I made a huge amount of changes on the AppStream
specification[1] in order to make the software matching easier, but it
still is a complex task. Additionally, you have to deal with ABI
incompatibilities and some distribution-specific madness.
So, I summary, the problem is relatively complex ;-)

Limba is a rebuilt version of Listaller, where I learned from past
mistakes - it is also greatly simplified and has a "no workarounds"
rule: If something is broken, fix it at its source. Listaller was 40%
workarounds for distribution-quirks and to make use of the package
management system for purposes which it was never designed for. The
concept was great, the idea was good, the goal was clear but the
result was terrible anyway ;-)

Let's see if Limba works, but the first results look good.

Cheers,
    Matthias

[1]: That thing which powers software centers like
GNOME-Software/Apper/Muon, see
http://www.freedesktop.org/software/appstream/docs/

-- 
Debian Developer | Freedesktop-Developer
I welcome VSRE emails. See http://vsre.info/