Re: [gentoo-portage-dev] going to need a 2.0.53-rc8

[Brian Harring]

On Fri, Nov 11, 2005 at 11:33:25PM +0900, Jason Stubbs wrote:
> On Friday 11 November 2005 22:53, Brian Harring wrote:
> > Hola,
> >
> > Short version is that via bug 112082 plus glibc upstream doing
> > something stupid, a lovely bug has reared it's head.  Basically,
> > users upgrading from glibc-2.3.5.200*.ebuild have libc.so-2.3.90.so,
> > and glibc-2.3.6.ebuild has libc.so-2.3.6.so .
> >
> > ldconfig views 2.3.90 as greater then 2.3.6; during merge, portage
> > views 2.3.5.200* -> 2.3.6 as an upgrade, and triggers an ldconfig
> > call.  Said call, and said upstream weird lib versioning results in
> > ld.so.6 being reset from libc-2.3.6.so to libc-2.3.90.so , which
> > obviously gets a bit screwed up when unmerge comes around and yanks
> > the lib.
> >
> > Az split off a patch for it (after lots of fun digging) to correct it;
> > we're going to need a rc8 covering this one offhand, since it's
> > invalid linking in certain cases.
> >
> > Thoughts/complaints/issues/further testing?
>
> Short answer: No.
Short response: reconsider.
;)

> Long answer: This is not a regression; you'll find the same problem in stable.
> It's an area where a slight error can break lots of things that are even
> slightly non-standard. This case where the bug is occurring is very
> non-standard and has not cropped up before (or at least hasn't been brought
> to anybody's attention) in the time since I (and you) have been with the
> project. Lastly, 2.3.5.200* is/was hard masked.

Yah it's a corner case, and yah few people are potential bitten by it 
right now- that said, the severity of being bitten by it is why this 
needs be released.  Think about it, it's a cockup in our lib 
handling... an area that needs to run pretty much perfect.  A corner 
case being spotted, even if upstream did something idiotic isn't 
particular acceptable in that chunk of code (imo).

Regression or not, I'm after having a fix deployed as quickly as 
possible.  Honestly, this reminds me of the early days of the daemon 
where occasionally it would lose the env and install nothing- didn't 
matter what the cause was, what mattered was that portage would go and 
rape my glibc installation, hosing my box.  Potential for hosing the 
machine (correctable or not) via portage is a big no no from where 
I'm sitting.  Bugs of this sort are more then capable of driving away 
a potential user/dev who has the misfortune of hitting it (masked or 
otherwise).

> My preference would be to put the patch into trunk and release .54_pre1 within
> the next 24 hours.

Releasing .54 == releasing cache, pre/post patch.  Yes getting those 
out for users to use is good, but see my earlier comments about 
sliding bug fixes in with large features.

.53.1 strikes me as a better route; we're tagging for a reason, not too 
hard to pop back and make the change.
~harring