| 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 |
Archives