Introduction
Hi all.
I was encouraged to introduce myself to this list and explain my cdd
project. I'm Darrin Thompson and I work for Progeny.
For the past 11 months I've been laboring over PDK. PDK stands for
Platform Development Kit. It is designed to automate the maintenance of
custom Debian and RPM based distributions.
PDK is designed to make managing full Debian or RPM based distributions
as much like managing source code as possible. With source code we
capture state in time with version control tools, and invoke compilers
on source trees to produce various "stuff".
That said, we've built pdk so that it remains mostly true to its vision.
Version control is built around git, a real version control system, and
the files stored in it are literally source code which can be diffed and
the results are meaningful. There are currently no magic daemons and you
don't need a dba to support the system. It just lives happily on a
filesystem. You can share your work with the world with nothing more
than a filesystem and the raw webserver of your choice.
The source code files are written in a component description language
we've cooked up for pdk and we refer to them as component descriptors,
or just components. The language the components are written in is pretty
obvious to read at a glance.
And just recently we added the ability to not only include one component
within another, but to include only desired portions, and the desired
portions can be described with a flexible condition.
The system described by a tree of components is intended to produce
three different outputs.
The first output is a package repository. PDK knows how to produce a
proper Debian repository out of the box, and can do so with any small or
large component.
The second output is an installable media set. This part was just added
to pdk and isn't yet mature. Currently with incantations and rain dances
we can produce d-i isos for our dcc distro. I think one person in
Mallorca built a distro using dcc that used Anaconda for Debian as the
installer.
The third output of a component tree is a metadata report. This is a
fairly general mechanism, but one of it's first targets is security
reporting. Currently there is very little command line interface to this
plumbing but it can be accessed via the pdk api. Basically it allows you
to attach single metadata values or link multiple entities to packages
in ways that reduce maintenance burden.
The metadata system is layered so that metadata in a shallow component
overrides metadata in a deeper component.
For instance, you may have pulled a core set of components to base a cdd
on, but use your own special apache component with custom packages.
The upstream core provider might ship the following metadata:
<dsc>
<cond> * apache (>2.0.0 <<2.0.51) </cond>
<meta>
<link>CAN-2006-99</link>
</meta>
</dsc>
Basically we said that apache 2 before 2.0.51 is vunerable to some CAN
number which I made up.
The upstream core provider might also ship 2.0.49 and have done a
backport of that security fix. In a shallower component they would
assert:
<dsc>
<cond> * apache (>=2.0.49-5) </cond>
<meta>
<unlink>CAN-2006-99</unlink>
</meta>
</dsc>
You, on the other hand, may have done a security backport to 2.0.47, and
you might have to assert in a yet shallower component:
<dsc>
<cond> * apache (>=2.0.47-7) </cond>
<meta>
<unlink>CAN-2006-99</unlink>
</meta>
</dsc>
The meta system can be used to attach all kinds of data to packages. You
might want to override the install menu order of a udeb, or break your
repo into funny named apt-components.
Currently the only way to access this information for complex reports is
to use the pdk api, iterate over the information and output the report
yourself. Writing such scripts is pretty easy.
There are still plenty of raw spot, bugs, annoyances, and unfinished
tasks. Right now I'm overhauling the installer/media generation code. If
you mostly put out repositories, pdk is ready for you now. If working on
cdd tools is something you consider fun, you are a wierdo and feel free
to ask questions of me directly or on the cl-workers mailing list. I'll
also happily answer pdk questions wherever I happen to get them, modulo
etiquette on this list.
Thanks if you are still reading. (I really need to stick this in our
wiki.)
http://componentizedlinux.org/
http://www.progeny.com/
--
Darrin
Reply to: