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 :)
firstname.lastname@example.org mailing list