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