Gentoo Archives: gentoo-dev

From: Duncan <1i5t5.duncan@×××.net>
To: gentoo-dev@l.g.o
Subject: [gentoo-dev] Re: Official overlay support
Date: Sat, 25 Mar 2006 02:57:24
Message-Id: pan.2006.03.25.02.54.41.343029@cox.net
In Reply to: Re: [gentoo-dev] Official overlay support by Chris Gianelloni
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