On Wed, 2008-10-29 at 20:47 -0400, Joshua Murphy wrote:
>
> Hrm. I know just enough about python to get myself in trouble here...
> but it looks like a python bug in magicking up the libc name and
> version... but the below is WAY outside my level of practice with
> python (it'll take re-reading and digging elsewhere a good few times
> if I'm ever to make sense of it...
>
> ------------------
> def libc_ver(executable=sys.executable,lib='',version='',
>
> chunksize=2048):
<deleted>
This is a very simple hack which simply doesn't work. Nice try. It's
not so much portage's fault as it is Python.
Basically what python is doing is opening it's executable
(/usr/bin/python') and doing a egrep for
(__libc_init)|(GLIBC_([0-9.]+))|(libc(_\w+)?\.so(?:\.(\d[0-9.]*))?)
Then it finds the matches and tries to apply some "logic" to decide the
best answer. On my system it's "GLIBC_2.0" and so platform.libc_ver()
returns ('glibc', '2.0') whereas my actual libc is glibc 2.8.
Obviously the person who wrote the function was trying to be
cross-platform. Python runs on many different platforms, POSIX and
non-POSIX. But the implementation is a bit "lazy" and, obviously,
inaccurate.
OTOH, if I were to take a guess I'd say not many people use the platform
module. I've been programming in python for over 10 years and this is
the first time I've even looked at it. Most code I've seen will use
sys.platform. It only returns the OS name but, when you're using a
cross-platform language, that's usually all you're worried about.
So partial blame goes to both python and portage: python for it's shoddy
implementation of platform.libc_ver() and portage for relying on it :-)
-a
