Re: [Plash] Packaging system

[Mark Seaborn]

"Thomas Leonard" <address@hidden> wrote:

> On 3/8/07, Mark Seaborn <address@hidden> wrote:
> > My design for plash-pkg ended up being different enough from
> > Zero-Install [...] from wanting to stick to how the Debian package system
> > works.
> 
> That's fine. I'd just like to make sure the text on the wiki is accurate.

I'll update it, although you're welcome to edit it too. :-)


> > > > "You have to declare trust for authors/packagers of all dependencies.
> > > > This does not scale."
> > >
> > > We'll make it scale when we have enough packages ;-) "Trust all keys
> > > on the Debian keyring" would be a possible policy, for example.
> >
> > I would rather just trust the key used to sign the debian Packages
> > file.
> 
> Doesn't that conflict with your next requirement:
> 
> > > > "If sandboxing were added, the inability to distinguish kinds of trust
> > > > would be a vulnerability."
> 
> If all you can say is "trust the master Debian keyring", you can't
> have different levels of trust anyway. If packages are individually
> signed, you can apply whatever policy you please (including grouping
> keys to get the Debian behaviour if you want).

There's no conflict.  Each application instance can be installed from
a different debian Packages file, and each application instance can be
trusted with different authority.  I mean small-d debian here
(referring to the package system, not Debian's distribution).  The
Packages file can come from any source you choose.  If you get the
Packages file via HTTP you need to do some hash or signature checking,
but after that there is no more signature checking to do.  You just
follow the hash references to get the individual .deb packages.

In this model, it is the responsibility of whoever provides the
Packages file to check that the individual .debs it lists are of good
quality and that they work well together.  For Debian, part of that is
checking that the .deb was signed by a developer before adding it to
the Packages index.

The signatures on the .deb packages provide an audit trail of how the
Packages file was constructed, and if someone wants to check it, they
can.  There should be tools that aid that process.  But most users
won't need to use them.

It's a similar situation with version control systems.  When a piece
of software is released, the developers are declaring that the code is
of a certain quality, has been tested, etc.  The version control
repository provides a audit trail, and it's possible to independently
audit all the changes since the last release.  While there's a chance
you'd want to do that, it's much less likely that you'd would want to
independently check that all the changes were made by a certain set of
committers, which is the analagous case to checking the signatures on
.deb files.  You'd assume that the SCM system is set up so only
trusted people can commit anyway, just as you'd assume that the Debian
servers are set up to only allow Debian developers to add packages.

You would only want to do these independent checks on the basis of
identity if you had some reason to suspect that a particular person's
changes were dodgy.

Incidentally, Debian falls down here because it doesn't provide a
standard way to link back to the version control system that the
package comes from, so it's not as easy to do audit checks as it could
be.  I think Conary provides this (not certain though).


> > Can a similar file be generated by 0launch?  Would it be possible to
> > split 0launch into steps that can be invoked separately from the
> > command line:
> 
> Yes. 0compile does it by running 0launch twice. Once in
> '--download-only' mode so you can download with a nice GUI, and then
> it uses the python API to write out the choices XML file, but the plan
> is to have 0launch write the file directly.

OK.  Presumably 0launch will be able to read the file to reproduce the
environment as well?


> > > [I]f someone provides an alternative to
> > > ROX-Lib (used by many ROX applications), you can add it with:
> > >
> > > $ 0launch --feed http://thirdparty.com/Alternative-ROX-Lib.xml
> > >
> > > It gets the program to extend from the <feed-for> element.
> >
> > My reservation about this is that the package name in <feed-for> is a
> > feed URL.
> 
> No it isn't, it's an interface. The syntax is:
> 
> <feed-for interface='...'/>
> 
> (we're often a bit loose with terminology though, because originally
> we didn't have 'feeds' so I used the word 'interface' to mean both
> interface and feed)

OK, I didn't appreciate the difference.  But doesn't this have the
problems I mentioned before?

"0launch --feed" is adding the feed to a global (well, per-user) list
isn't it?  Does that mean that all applications that depend on the
interface (assuming no versioned dependencies) will use the new feed?
Is it possible to choose per-application?


> [ packages with hundreds of libraries ]
> 
> > Would the length of LD_LIBRARY_PATH start to become a problem if those
> > were all packaged with Zero-Install?
> 
> Probably. I'd guess linking is O(n^2) with the number of dependencies
> when adding to LD_LIBRARY_PATH.
> 
> (the correct way is to use a different environment variable for each
> library and have the program link to the chosen version directly, but
> the LD_LIBRARY_PATH approach works well for existing packages).

I noticed that where interface A depends on B, it is A that contains
the <environment name="PYTHONPATH"...> setting and not B.  That seems
a little counterintuitive.  It makes sense if this is seen as an
argument to A, but then it contains a path into B.


By the way, how about adding an apt sources.list line to the
installation instructions for Debian etch on the Zero-Install web
site?

Cheers,
Mark