On Tue, Dec 23, 2014 at 09:46:28AM -0500, Anthony G. Basile wrote: > On 12/23/14 09:39, William Hubbs wrote: > > On Tue, Dec 23, 2014 at 08:45:49AM -0500, Anthony G. Basile wrote: > >> On 12/22/14 23:55, William Hubbs wrote: > >>> All, > >>> > >>> this discussion got side-tracked into gcc, which was not my intent; > >>> let's go back to my specific question about glibc. > >>> > >>> On Mon, Dec 22, 2014 at 10:22:41PM +0100, Andreas K. Huettel wrote: > >>>>> some of such software is > >>>>> binary, some other is too large to be updated regularly. > >>>> Please give REASONS why things should remain maintained. So far (except > >>>> for > >>>> the gcc-3/hardened explanations, and for gcc-3 doing more fortran than > >>>> gcc-4(??)) this is mostly mumbo-jumbo about "someone might need it", > >>>> proprietary binary blobs (should we even care? if yes, why?) and similar. > >>> > >>> I vote that we shouldn't care about proprietary binary blobs. > >> Oh dear god this is going from bad to worse. I love blobs as much as > >> the next person but there are people that need this stuff if gentoo is > >> to be useful for them. Let's not care about blobs and shut down > >> linx.net where Tony Vroon (Chainsaw) uses gentoo and runs broadcom II > >> which need blobs. > > I have never heard him say that keeping old software in the tree is > > necessary for the blobs he uses. If that is the case, that is something > > that must be considered. I was just echoing the current policy about > > blobs; they are not a reason to block stabilization of other > > packages etc. > > > > William > > > > > > That's not what you said. I was responding to "I vote that we shouldn't > care about proprietary binary blobs" not to "I have never heard him say > that keeping old software in the tree ..." > > I test for him on his equipment and there you must care about > proprietary blobs.
Sure, but I was just saying that Gentoo policy doesn't currently care about proprietary blobs. Specifically, I don't think a proprietary blob or the breakage of one can be used as a reason to block stabilization of a new version of a package or removal of an old version of the package wrt the main tree. That's my understanding of our policy; however, as usual, I am open to being corrected. William
signature.asc
Description: Digital signature