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
pgpnti3nLJSer.pgp
Description: PGP signature
