On Sat, Mar 25, 2006 at 08:37:24PM +0100, Paul de Vrieze wrote: > On Friday 24 March 2006 20:18, Chris Gianelloni wrote: > > I really can't think of much besides kernel + toolchain that can have > > such devastating effects to the rest of the tree. The only other > > massive breakages would be via eclasses, which was my main target. > glibc is a good candidate. And portage a second one. *libc in general. binutils coreutils (Screwing up this is really fun, sort/xargs/tail etc.)
And a general class, the reason I've had stuff in my own overlays: - Trying to develop clean/safe automated upgrade paths for complex packages. Early versions of these tend to do nasty things to data (openldap was esp. painful). > > Does anyone have any ideas how we could resonably reduce problems > > reported from things such as toolchain breakages in an overlay, yet > > still not punish the people running the overlay by disallowing it? I > > surely wouldn't want to limit the toolchain maintainers from being able > > to enjoy the use of an overlay if they wished it. > Perhaps we could ask people who run overlays with dangerous ebuilds, to have > these ebuilds protected by some environment variables. (The var must be set > for the ebuild to work.) Only if portage can check the variable before starting to compile any packages. -- Robin Hugh Johnson E-Mail : [EMAIL PROTECTED] GnuPG FP : 11AC BA4F 4778 E3F6 E4ED F38E B27B 944E 3488 4E85
pgpXPDpRpLVa5.pgp
Description: PGP signature
