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