Chris,
   In response to your question "Would people use this" ... I can say for
certain that I would most definitely use it. I've been using catalyst for a
while to build images and systems for various purposes at work.

   I often build different types of images using variations on the spec
files and in order to not pollute my tested working environments, I copy the
whole thing into a new dir. I currently use some sed magic to set the
absolute paths but if catalyst used relative paths it would make life just a
little better.

   The big thing is when I make changes in a development spec file and I
want to compare those to the original I need to sort through the absolute
path differences in order to find the lines that actually changed. Also,
since the absolute paths change per dir, a simple diff -rq specs.orig
specs.new will show all my specs as changed. It would be great to know
exactly what files changed without manually sifting them.

So, FWIW ... I would vote thumbs up to the suggestions. =)

Thanks for the great tool. There really is no replacement for catalyst
(trust me, I've tried them all).
John

On 4/23/07, Chris Gianelloni <wolf31o2@gentoo.org> wrote:
>
> On Mon, 2007-04-23 at 23:39 +0200, Ramon van Alteren wrote:
> > This puzzles me, if making a tool easier to use for it's users isn't a
> > valid reason for hacking at the tool, then what is ?
>
> Well, I know I have said this before, but I'll say it again here.  We
> develop catalyst for our own usage first, and everyone else second.  If
> it doesn't directly impact Release Engineering, it immediately gets a
> back seat to changes that we need/want.  When I said "you" here, I meant
> you specifically, not any other form of you.
>
> > It was a dual request, if nobody on list would be using the
> > functionality I'll maintain a patch outside the tree for our benefit.
>
> This was really my question.  Would other people use it?
>
> One of the biggest problems that we have had with catalyst is people
> that want to change catalyst to meet their own specific needs and our
> need to balance things out so that we don't end up with unused code
> paths.  Having a single, consistent interface for the spec files allows
> for much simpler support on a product that we honestly wished we didn't
> have to support, at all.  If the change is something that lots of people
> would likely use, such as the stage4 target, then we will add it even if
> we don't use it ourselves.  Our general rule is don't change anything
> unless there is a really good reason.  As I said, simply making things
> slightly more convenient isn't really a good enough reason, IMO, unless
> a lot of people would use the functionality, and even then, it would
> depend on code availability and maintainability.  Of course, writing up
> a patch resolves the first issue, but the second would still remain.
>
> --
> Chris Gianelloni
> Release Engineering Strategic Lead
> Alpha/AMD64/x86 Architecture Teams
> Games Developer/Council Member/Foundation Trustee
> Gentoo Foundation
>
>