On 2/22/06, Darrin Thompson <[EMAIL PROTECTED]> 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 ----
