Re: PDK of Componentized Linux
On 2/22/06, Darrin Thompson <darrint@progeny.com> wrote:
> 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
what you're doing looks really interesting ...
with smart pm there is already the possibility to select "channels" ..
but i've never tested it ..
http://labix.org/smart
--
----
http://dsslive.org
----
Reply to: