Re: [Plash] Packaging system (was: Plash Wiki)

[Thomas Leonard]

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.

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

[...]
> To clarify, I meant the sort of trust you're referring to here.  When
> I launch gedit I want to be sure that I am getting a program that was
> signed by the public key I specified when I installed gedit,

I agree. The trust database should record which domains the key is
trusted for. Then the 'confirm trust' box can say "Note: you already
trust this key for software from XXX.org" when confirming a key for
YYY.org.

> > > "Zero-Install does not provide a way to refer to an immutable package.
> > > There is no way to reproduce a configuration."
> >
> > This is not true. In fact, 0compile stores a complete record of the
> > configuration in a file called "build-environment.xml", so that you can
> > reproduce a build exactly using the digests of each dependency (header
> > files and build tools). It also stores the versions, in case you want to
> > use a different arch but still get it as close as possible. See the
> > Pager 1.1 binary for an example.
>
> That sounds good.  It would be handy if that record were referenced by
> binary packages.

It's inside the binary packages already:

- Download and extract a binary (e.g. ROX-Filer 2.6):
 http://kent.dl.sourceforge.net/sourceforge/rox/rox-filer-linux-x86-2.6.tar.bz2

- Create a new empty directory and copy the build file as 0compile-env.xml:

$ mkdir rebuild-rox
$ cp rox-filer-linux-x86-2.6/0install/build-environment.xml \
rebuild-rox/0compile-env.xml

- Run '0compile build' inside the new directory.

[ minor limitation at present: the dependencies must be in the cache;
0compile will complain if not, instead of offering to download them as
it should ]

> That would give an audit trail recording the
> compilers that built the package, the compilers that built the
> compilers, and so on.

Yes, exactly.

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

> > [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)

> > The current behaviour works well for CVS checkouts, where you want to
> > use whichever is more recent: your checkout or the latest release
> > (given that you may have forgotten about the checkout weeks ago).
>
> That's not what you want if you've made local changes though.  I like
> what Conary does here: it can attempt to merge your changes into the
> newer version of the package for you.

Running 'cvs update' will do the same thing (since it updates the
version number as well as merging), but it doesn't happen
automatically.

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

> Do you find there are many programs that can't be relocated by setting
> environment variables?

Games mainly. They seem to like starting with 'cd /usr/games/...' for
some reason.


--
Dr Thomas Leonard               http://rox.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1