1 |
On Sat, 2007-09-22 at 08:01 +0100, Steve Long wrote: |
2 |
> > I've already stated my preference for not doing *anything* outside of |
3 |
> > merging packages in the stages. |
4 |
> With respect, this is a little confusing. I didn't get past the learning |
5 |
> curve for catalyst, but it's clearly not the same as simply merging |
6 |
> packages, or you wouldn't need a special tool. |
7 |
|
8 |
The tool does things like setting up the chroot. The code run by |
9 |
catalyst to get a stage3 from a stage2, not counting things like chroot |
10 |
setup, is "emerge -e world" just like going from a stage2->stage3 by |
11 |
hand. Anyway, you don't really need to understand it, as I do, and |
12 |
vapier does. If you're really interested, learn a bit about catalyst. |
13 |
Uninformed opinions help no one. |
14 |
|
15 |
> It seemed to me that a clean, *simple* solution which would work for any |
16 |
> future packages that might also need this functionality was proposed. Why |
17 |
> not just use it? It's only one command, and the standardisation would mean |
18 |
> users could rely on the mechanism for system recovery. |
19 |
|
20 |
Uhh... what does adding "emerge --config" have to do with catalyst? |
21 |
There's nothing stopping vapier/anyone from adding the emerge --config |
22 |
steps to the ebuilds. I simply said that I'm not wanting to add code to |
23 |
run those to catalyst for the reasons I have already stated. In no way |
24 |
does that impact the usefulness of the config code for end users. It |
25 |
only affects what goes into the stages. |
26 |
|
27 |
> Or am I missing some deeper technical implication? |
28 |
|
29 |
Yup. |
30 |
|
31 |
-- |
32 |
Chris Gianelloni |
33 |
Release Engineering Strategic Lead |
34 |
Alpha/AMD64/x86 Architecture Teams |
35 |
Games Developer/Foundation Trustee |
36 |
Gentoo Foundation |