| 1 |
On Tue, 13 Jun 2006 23:19:51 +0100 |
| 2 |
Stuart Herbert <stuart@g.o> wrote: |
| 3 |
|
| 4 |
> -----BEGIN PGP SIGNED MESSAGE----- |
| 5 |
> Hash: SHA1 |
| 6 |
> |
| 7 |
> Michael Cummings wrote: |
| 8 |
> | Chris Gianelloni wrote: |
| 9 |
> |>> Using your example, if it will *never* make it into the tree, |
| 10 |
> then what |>> is it doing on *.gentoo.org infrastructure? |
| 11 |
> | |
| 12 |
> | OK, I'll speak up. I plan on using overlay.gentoo.org for the perl |
| 13 |
> team | overlay repository. |
| 14 |
> |
| 15 |
> [snip] |
| 16 |
> |
| 17 |
> You're not alone. |
| 18 |
> |
| 19 |
> The webapps overlay contains ebuilds that may never make it into the |
| 20 |
> tree. We have a lot of packages that we maintain, but which don't |
| 21 |
> pass our upstream requirements [1] at this time. We're doing our |
| 22 |
> best to work with $upstream on resolving such issues, but we're never |
| 23 |
> going to achieve a 100% success rate. |
| 24 |
|
| 25 |
No-one is objecting to these project-local overlays. The objection is |
| 26 |
to a system-wide overlay. |
| 27 |
|
| 28 |
To comment on the subject - as a system-wide overlay sunrise does look |
| 29 |
a lot like a fork of the man tree. This could be alleviated by banning |
| 30 |
several things from the overlay; eclasses are already listed, but |
| 31 |
I think it would be a good idea to include key system elements (e.g. |
| 32 |
kernel, toolchain, baselayout - perhaps the sys-* categories) in the ban |
| 33 |
for sunrise. Anything hacking around with such critical components |
| 34 |
should be in their own specific overlay. This is key to the |
| 35 |
objections; that sunrise is system-wide, not local to a particular area. |
| 36 |
|
| 37 |
-- |
| 38 |
Kevin F. Quinn |
Archives