Chris Gianelloni wrote: > On Fri, 2007-09-21 at 17:45 -0400, Mike Frysinger wrote: >> the compromise is simple: catalyst runs --config at the end of stage3 for >> appropriate packages, but as to what those things actually do is left in >> the ebuilds. > > I've already stated my preference for not doing *anything* outside of > merging packages in the stages. With respect, this is a little confusing. I didn't get past the learning curve for catalyst, but it's clearly not the same as simply merging packages, or you wouldn't need a special tool.
> Were this >stage3, I wouldn't care. > Anyway, I'd much rather leave everything as it is now than add the > emerge --config stuff. You're free to add it to the ebuilds, of course, > which would satisfy the people that want it, but I would prefer not add > it to the stages, even if it is documented in the Handbook, as it isn't > required. Basically, I'd rather we either throw it into the earlier > stages, or not do it at all. You've given good reason on why, while > technically feasible since we're only caring about bash at this time, it > is still a bad idea as it opens us up to yet another slippery slope. I > completely see your point, which is why I'm taking the stance that > things are best left as they are now. > It seemed to me that a clean, *simple* solution which would work for any future packages that might also need this functionality was proposed. Why not just use it? It's only one command, and the standardisation would mean users could rely on the mechanism for system recovery. Or am I missing some deeper technical implication? -- [EMAIL PROTECTED] mailing list
