1 |
Chris Gianelloni posted <1143227928.17575.44.camel@×××××××××××××××××.net>, |
2 |
excerpted below, on Fri, 24 Mar 2006 14:18:48 -0500: |
3 |
|
4 |
> On Fri, 2006-03-24 at 09:47 -0500, Aron Griffis wrote: |
5 |
>> Chris Gianelloni wrote: [Fri Mar 24 2006, 08:55:30AM EST] |
6 |
>> > As I've said, my only request is a single policy that before an overlay |
7 |
>> > can become publicly readable on overlays.gentoo.org (which is Gentoo |
8 |
>> > infrastructure) that it does not break packages in the main tree that |
9 |
>> > are not in the overlay. |
10 |
>> |
11 |
>> This makes sense, but what's the content of such a policy? Take your |
12 |
>> gcc-5.1.99 example: say it "breaks" lots of packages in portage. Is |
13 |
>> it not allowed to be in a publicly accessible overlay in that case? |
14 |
>> If that's not the policy, then what policy allows gcc-5.1.99 but still |
15 |
>> covers the ground you want covered? |
16 |
> |
17 |
> I see your point here and honestly do not have an answer. I don't want |
18 |
> to limit what people can do in the overlays so much as reduce the |
19 |
> "collateral damage" that can be done. Honestly stuff like the toolchain |
20 |
> is a bit of an exception only because that information all shows up on |
21 |
> an "emerge --info" already. |
22 |
|
23 |
With current in-tree gccs there's another exception as well -- the |
24 |
slotting and eselect/gcc-config functionality makes it very easy to switch |
25 |
gccs where necessary. It's that functionality that allowed me to test out |
26 |
gcc-4.0 and 4.1 with few problems, all of which were easily resolved with |
27 |
a quick gcc switch, save for one with KDE and libstdc++ that was easy |
28 |
enough to work around once I was aware of it. |
29 |
|
30 |
I'd suggest that the "no break tree" policy apply here to the extent that |
31 |
gcc in an official overlay must continue to support the usual slotting and |
32 |
eselect/gcc-config functionality, thus allowing a quick reconfigure to a |
33 |
generally working system. |
34 |
|
35 |
Of course, there's a wrench thrown in the next time gcc decides to go with |
36 |
a seriously incompatible c++ implimentation, but I think the usual die |
37 |
unless some exotic I_WANT_TO_BREAK_MY_GENTOO_SYSTEM_WITH_A_L33T_GCC |
38 |
variable is set, with an appropriately dire warning in the die, covers |
39 |
that eventuality. |
40 |
|
41 |
The rest of the toolchain... Kernel, I've never run into a problem with |
42 |
support because I choose to grab my kernels directly off of kernel.org, |
43 |
and I think that should continue. Is binutils fully slotted and |
44 |
binutils-config or the like yet working? |
45 |
|
46 |
-- |
47 |
Duncan - List replies preferred. No HTML msgs. |
48 |
"Every nonfree program has a lord, a master -- |
49 |
and if you use the program, he is your master." Richard Stallman in |
50 |
http://www.linuxdevcenter.com/pub/a/linux/2004/12/22/rms_interview.html |
51 |
|
52 |
|
53 |
-- |
54 |
gentoo-dev@g.o mailing list |