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