<div dir="ltr"><div class="gmail_extra">Thanks Matthias & Mattias for your comments,<br><br></div><div class="gmail_extra">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.<br></div><div class="gmail_extra"><br><div class="gmail_quote">On 8 December 2014 at 15:38, Matthias Klumpp <span dir="ltr"><<a href="mailto:matthias@tenstral.net" target="_blank">matthias@tenstral.net</a>></span> wrote:<br><div>><span class="im">> 3. Applications can be installed into ~/.local without giving them root<br>>> privileges</span> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":3cd" class="" style="overflow:hidden">This actually has some security implications, e.g. a malicious<br>
software can taint the other applications and use them to hide itself.<br>
It also leads to some kind of annarchy on one system, where different<br>
users are running different software versions (and combinations of<br>
them).<br></div></blockquote><div><br></div><div>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.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div id=":3cd" class="" style="overflow:hidden">
<span class="">> 6. Ideally, all of this should be an addition to a tarball, so sites can<br>
> offer a single .app.tar.gz file, and users without the installer mechanism<br>
> can extract the files and launch the application manually.<br>
<br>
</span>Why should they want to do that? This would not only have all problems<br>
described in 3., but also have other technical difficulties. E.g. you<br>
have version 1.0 of application X which creates some configuration in<br>
your home directory. Then you decide to "test" version 2.0 that way,<br>
which migrates your configuration to a higher version. Then you decide<br>
to switch back to 1.0, or simply launch 1.0 because you forgot about<br>
the local copy. Version 1.0 can't read 2.0 configuration or in the<br>
worst case might even corrupt it, and then you have new trouble.</div></blockquote><div><br></div><div>I'm not quite sure about the link between that point and upgrading/downgrading config.<br><br></div><div>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.<br><br></div><div>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.<br><br></div><div>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..."<br><br></div><div>Mattias:<br><br></div><div>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.<br><br>Thanks,<br>Thomas<br></div></div><br></div></div>