1 |
Chris, |
2 |
In response to your question "Would people use this" ... I can say for |
3 |
certain that I would most definitely use it. I've been using catalyst for a |
4 |
while to build images and systems for various purposes at work. |
5 |
|
6 |
I often build different types of images using variations on the spec |
7 |
files and in order to not pollute my tested working environments, I copy the |
8 |
whole thing into a new dir. I currently use some sed magic to set the |
9 |
absolute paths but if catalyst used relative paths it would make life just a |
10 |
little better. |
11 |
|
12 |
The big thing is when I make changes in a development spec file and I |
13 |
want to compare those to the original I need to sort through the absolute |
14 |
path differences in order to find the lines that actually changed. Also, |
15 |
since the absolute paths change per dir, a simple diff -rq specs.orig |
16 |
specs.new will show all my specs as changed. It would be great to know |
17 |
exactly what files changed without manually sifting them. |
18 |
|
19 |
So, FWIW ... I would vote thumbs up to the suggestions. =) |
20 |
|
21 |
Thanks for the great tool. There really is no replacement for catalyst |
22 |
(trust me, I've tried them all). |
23 |
John |
24 |
|
25 |
On 4/23/07, Chris Gianelloni <wolf31o2@g.o> wrote: |
26 |
> |
27 |
> On Mon, 2007-04-23 at 23:39 +0200, Ramon van Alteren wrote: |
28 |
> > This puzzles me, if making a tool easier to use for it's users isn't a |
29 |
> > valid reason for hacking at the tool, then what is ? |
30 |
> |
31 |
> Well, I know I have said this before, but I'll say it again here. We |
32 |
> develop catalyst for our own usage first, and everyone else second. If |
33 |
> it doesn't directly impact Release Engineering, it immediately gets a |
34 |
> back seat to changes that we need/want. When I said "you" here, I meant |
35 |
> you specifically, not any other form of you. |
36 |
> |
37 |
> > It was a dual request, if nobody on list would be using the |
38 |
> > functionality I'll maintain a patch outside the tree for our benefit. |
39 |
> |
40 |
> This was really my question. Would other people use it? |
41 |
> |
42 |
> One of the biggest problems that we have had with catalyst is people |
43 |
> that want to change catalyst to meet their own specific needs and our |
44 |
> need to balance things out so that we don't end up with unused code |
45 |
> paths. Having a single, consistent interface for the spec files allows |
46 |
> for much simpler support on a product that we honestly wished we didn't |
47 |
> have to support, at all. If the change is something that lots of people |
48 |
> would likely use, such as the stage4 target, then we will add it even if |
49 |
> we don't use it ourselves. Our general rule is don't change anything |
50 |
> unless there is a really good reason. As I said, simply making things |
51 |
> slightly more convenient isn't really a good enough reason, IMO, unless |
52 |
> a lot of people would use the functionality, and even then, it would |
53 |
> depend on code availability and maintainability. Of course, writing up |
54 |
> a patch resolves the first issue, but the second would still remain. |
55 |
> |
56 |
> -- |
57 |
> Chris Gianelloni |
58 |
> Release Engineering Strategic Lead |
59 |
> Alpha/AMD64/x86 Architecture Teams |
60 |
> Games Developer/Council Member/Foundation Trustee |
61 |
> Gentoo Foundation |
62 |
> |
63 |
> |