Re: [gentoo-dev] rfc: glibc versions prior to 2.19-r1

[William Hubbs]

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