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