Re: PDK of Componentized Linux

[Darrin Thompson <darrint@progeny.com>]

On Tue, 2006-02-21 at 14:55 -0300, Otavio Salvador wrote:
> How is PDK support for more then one origin. Let me give an exemple:
> 
>  I have Debian as first origin but I also need to have customized
>  packages on the media and to control them too. How PDK support it?
> 

Good question.

Suppose last month I ran debootstrap etch and used the chroot
environment to do some useful work. Then I ran rm -rf and nuked the
whole chroot.

Today I do the whole thing again. I'm going to get different results.
Furthermore, it's going to be tricky to go back and recreate last
month's state.

We do things differently from a lot of Debian tools. A fundamental
principle of PDK is that we don't tolerate uncontrolled change.

Generally Debian tools support stable, testing, and unstable as the
three choices for doing whatever the tools does. We break from that
tradition by design.

A package in a pdk component looks like this:

    <dsc>
      <name>apache2</name>
      <dsc ref="md5:d94c995bde2f13e04cdd0c21417a7ca5">
        <name>apache2</name>
        <version>2.0.53-5</version>
      </dsc>
      <deb ref="md5:5acd04d4cc6e9d1530aad04accdc8eb5">
        <name>apache2-common</name>
        <version>2.0.53-5</version>
        <arch>i386</arch>
      </deb>
      <!-- many more binaries -->
    </dsc>

This component would probably be a part of one named apache.xml, or
maybe webserver.xml. It could be included into a component named
lamp-stack.xml.

That component captures and cements a lot of state. Even if I lost my
local copy of the packages, if they were available elsewhere, I could
find them again and be confident that I haven't changed the
distribution.

While we have some nice ways to include portions of components into
other components, all the "leaves" of the component tree are these
references: [package-type, md5 sum or sha-1 sum].

We include tools to help automate updating descriptors in place. I could
run pdk update on this component using an etch channel, and the
referenced packages would be replaced by etch apache packages. We
provide plenty of feedback so you aren't being blindly trusting when
doing this stuff. A typical use is pdk upgrade --dry-run apache.xml.
That gives you a report so you can verify that you are really doing what
you think you are doing.

We also include a tool called pdk semdiff which can compare two
components and give you the "semantic" difference between the two. For
instance, did I add a new package, drop a package, upgrade, downgrade?
Most importantly, disregarding package version, did the metadata of my
distribution change at all? (relation to known security vulnerabilities,
installation order, etc.)

> also... how it store the different source of packages?
> 

The places you could obtain new packages are called channels. The
resolve and upgrade commands use channels to automatically insert and
upgrade packages respectively.

Once you go to make a repository or media, channels are no longer a part
of the picture. Only local components and the local package cache are
used.

Because of this it is possible to go back in time, regenerate a repo or
media and get the same result as you would have before.

Again, going back to our core metaphor, we try to make managing a
distribution like managing source code. We want that source code to
capture the state of the distribution in its entirety. Perhaps from
looking at our use of md5sums, you can see we are deadly serious about
it. :-) 

Furthermore, we hope to be able to build up a library of common
maintained components, which can be pulled directly, removing the need
for every person to independently upgrade their components against
channels. Upgrading these outside channels would be more like upgrading
a local source tree with cvs update. (...really a whole lot more like
git-pull which is more flexible than plain cvs update.)

woooo long. Hope that helps.

One more thing: I'm considering replacing:

      <deb ref="md5:5acd04d4cc6e9d1530aad04accdc8eb5">
        <name>apache2-common</name>
        <version>2.0.53-5</version>
        <arch>i386</arch>
      </deb>

with:

      <deb ref="md5:5acd04d4cc6e9d1530aad04accdc8eb5">
        <cond> apache2-commmon (=2.0.53-5) [i386] </cond>
      </deb>

which I think is a whole lot easier on the eyes and just as obvious to
read for the first time.

--
Darrin