Re: PDK of Componentized Linux
On Wed, 2006-02-22 at 11:51 +0200, Tzafrir Cohen wrote:
> That depends. You could keep a whole repository with pdumpfs or the
> likes, just like http://snapshot.debian.net/ .
>
I very well could. The current architecture is in place because it is
simple. Also keep in mind, pdk is capable of working with rpms also, so
I tend to avoid getting too intimate with apt when dealing with the
universe of all available packages.
> 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?
>
What do you mean by track?
[ Debian ] - [ My CDD ] - [ Installed System ]
For the installed system to get security updates, the updates need to be
in the CDD. If the CDD is updated, some human must be involved to verify
that the updates work. The amount of work that person does may vary
depending on how much customization has been done, but there can't be an
automated revolving door between the installed system and Debian.
That's something I take as an axiom for PDK. Perhaps I misunderstand
what you mean by "track"?
> This sounds to me like server-side resolution as opposed to client-side
> resolution used by apt.
A couple of your questions here seem to reflect the fact that you are
looking at pdk from the perspective of and end user installed system,
where pdk really isn't a factor at all. All pdk does is make media and
repositories for apt and friends to consume. The end user just uses apt
and friends and things just work (assuming you've done your QA.)
Now when I say "All pdk does..." I'm waving my hands of a lot of design
considerations.
PDK is about maintaining a definition of a distribution. The definition
of a distribution could, as you said, be adequately captured by Packages
files. (Plus what's needed for building media.) But at any rate, the
repository has all the state at a point in time. Why not just capture
it?
Here's the situation that originally influenced my thinking about
components:
In barren boring commercial land, I've had to work on some sizable
distros where the entire product could be summed up like this:
W = { subset of stable }
S = { subset of testing }
C = { packages customized for customer by Progeny }
E = { custom packages provided by customer }
(debsolve W S C E over woody) -> repository
I don't think I need to tell the folks on this list that putting
together that distro is going to be a lot of work.
But the thing I noticed, is that the definition I gave above is precise.
Given some supplemental information, and a formal way of representing it
all, I could realize complete distributions. What a foundation that
would be for maintaining customized distros of any kind.
What could I build on that foundation? Clearly that info can be put into
version control. That's implemented now. How about automatically farming
out rebuilds of customized packages?
The thing I find interesting is that the meat of the definition of a
distro changes very little over time. What does change over time is
stable and testing. What I need to be able to do over time is
selectively update from my upstream channels and verify that things
still work. I can then pass those updates down to my customers.
Furthermore, the thing I need to be able to do is trust somebody else to
do some of pulling from upstream channels. I'd like to import their
whole history. I'd like to be able to revert just their work back to a
previous point in time if I discover a problem. (Hence, we are based
around git, not svn.)
Where we stand now is that we have a very nice system of updating from
channels, and pulling subsets of components is newly implemented. The
states created by updates are text files and are therefore easy to poke
into version control. We can sling around repositories from these
definitions with ease.
I can't depsolve in a component yet, but I recently figured out how to
do it in a package format independent manner, and I'm using that in
media generation now. (Needless to say, I was stoked when I figured it
out. Smartpm rocks.)
Also, I can't build farm packages yet. But I have some ideas.
At the moment I'm consumed with PDK generating media better and
answering questions about PDK.
> Hmmm....
>
> If you start from scratch, shouldn't you pick a checksum that is a bit
> bigger than md5 (and maybe even sha1)?
>
I did actually, but dsc's made my life miserable. Now any package can be
found by either md5 are sha-1 checksum. It's just that at the moment,
I'm finding deb files using the md5 sums. I'll probably switch to sha-1
when dsc's and Packages files make them available. Fighting the upstream
file formats was just no fun.
--
Darrin
Reply to: