Re: PDK of Componentized Linux
On Tue, Feb 21, 2006 at 01:48:47PM -0500, Darrin Thompson wrote:
> 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.
That depends. You could keep a whole repository with pdumpfs or the
likes, just like http://snapshot.debian.net/ .
Note that what you actually need to save is the old packages in the
repository's pool as well as a Packages file for each snapshot. Keeping all
the old files in the pool is basically a matter of not deleting packages
(or not deleting unreferenced packages). Daily/weekly Packages files
take some more space, but can probably be saved efficiently in a
repository, as the bulk of them doesn't change.
>
> We do things differently from a lot of Debian tools. A fundamental
> principle of PDK is that we don't tolerate uncontrolled change.
What if you want the "current" version to track Debian Stable's security
source?
>
> 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 sounds to me like server-side resolution as opposed to client-side
resolution used by apt.
Server-side resolution is also used by e.g. Ximin RedCarpet and also of
Aduva's OnStage (which is where I worked in the past). It is very
handy to gain total control of the packages you'll install. The problem
with that is that packages will eventually be installed by an apt-based
tool that will have its own mind regarding dependencies. And thus you
have to be very careful not to collide with them.
As you probably know, apt considers locally-installed packages as
legitimate packages in its repository. So if the user installed a
package using dpkg --install, that package will affect apt-based tools
but not your tools
The two tools I mentioned above work by installing RPMs with --nodeps
and sometimes even with --force (at least last time I checked: around
2003. As I said: former employee)
>
> 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.
The Debian equivalent for those is a Packages file, and a component is
replaced with a specific virtual package. Installing that virtual
package installs a few specific packages.
Another question: what happens on the next upgrade?
It seems that CL seems to consider the system as mainly static and
non-evolving. However from my experince systems in the wild tend to
install part of the updates if at all. Not to mention that they don't
install all the packages and they install external packages.
>
> 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. :-)
Hmmm....
If you start from scratch, shouldn't you pick a checksum that is a bit
bigger than md5 (and maybe even sha1)?
>
> 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.
--
Tzafrir Cohen icq#16849755 +972-50-7952406
tzafrir.cohen@xorcom.com http://www.xorcom.com
Reply to: