On Mon, 8 Dec 2014 17:54:09 -0800 Thomas Kluyver <[email protected]> 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 > <[email protected]> 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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
