On Fri, 2005-11-11 at 17:06 -0600, Brian Harring wrote: > 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). >
> ~harring Would it be that hard to put an exception check for lib versioning (or any package) to check a file of known bad versioning for just such instances and use the also listed regard_as_version so that it is treated properly. It would mean not having to patch portage to catch specific versioning flaws each time they crop up. Just add it to the list. eg: libfoo-2.3.5.200* libfoo-2.3.5_p200* libc-2.3.90.so libc-2.3.5_p90 -- Brian <[EMAIL PROTECTED]> -- [email protected] mailing list
