On Tue, Apr 22, 2008 at 09:58:57AM -0700, Chris Gianelloni wrote: > On Tue, 2008-04-22 at 20:18 +0800, Max Arnold wrote: > > 1. Create small, task-oriented stage4 for fixed hardware configuration > > 2. Deploy it to several machines (now looking for deployment variants and > > installers) > > 3. Maintain it (updates) > > This is rather funny, since I'm adding support for exactly this stuff to > catalyst (and via other tools which will utilize catalyst).
Yes, synchronicity exists :) Maybe I will be an early adopter? > > I want special build host, where all binary targets are built. Its setup > > should be easily repeatable by other developers (i.e. every task should be > > scripted, > > without manual tweaks like 'chroot here and patch/emerge this'). Catalyst > > with > > specs and overlays seems fine to me. > > Sure. In fact, I have 2 different "host types" right now, a "master" > and a "build host" though they can reside on the same machine. Which roles they have? > > - Is it possible with catalyst to produce icremental binary updates (i.e. > > feed it with > > new snapshot and take set of updated packages as a result)? To me seems > > it is not. > > Huh? Have you ever looked at the package cache? > > ls -l /var/tmp/catalyst/packages/stage4-i686-custom/All > ~/before.txt > catalyst -f ~/stage4-i686-custom.spec > ls -l /var/tmp/catalyst/packages/stage4-i686-custom/All > ~/after.txt > diff -u ~/before.txt ~/after.txt > > > - What about sequential stage4 generation without purging cache? > > What about it? You described my thoughts more clear (package cache, before.txt and after.txt) My doubts was about using grp target. > Well, I think that you need to spend a bit more time figuring out what > catalyst can already do before asking for additional support. Much of > what you've asked here, catalyst already does. ;] Yes, that is what I'm currently doing :) -- [email protected] mailing list
