[issue1322] platform.dist() has unpredictable result under Linux
Zooko O'Whielacronx
report at bugs.python.org
Fri Mar 20 14:48:52 CET 2009
Zooko O'Whielacronx <zooko at zooko.com> added the comment:
I just read back through this ticket, but I didn't understand exactly
what MAL wanted to have different from what this Python function
currently does:
http://allmydata.org/trac/tahoe/browser/src/allmydata/__init__.py?rev=20081125155118-92b7f-f74fc964ebd9d3c59afde68b6688c56ce20cca39#L31
MAL, could you please restate the changes you want?
By the way I think there is some confusion about what is standardized by
LSB. As far as I know this one page is the complete spec:
http://refspecs.freestandards.org/LSB_3.2.0/LSB-Core-generic/LSB-Core-generic/lsbrelease.html
and it doesn't specify the existence of any file that we can parse. So
the quote you mention: "Linux System Base-compliant systems should have
a file called /etc/lsb_release, which may be in addition to a
distribution-specific file." is just wrong. More's the pity -- most
implementations use a file named /etc/lsb-release, and we can parse
that, and if we do it is much faster than executing the lsb_release
executable in a subprocess. The slowness of invoking subprocess is why
I was forced to back off from my original patch of merely using only
what the LSB offers.
A second problem with relying on LSB is, as I've mentioned, that some
Linux distributions don't come (by default) with the de-facto-standard
"lsb_release" executable although they do come with an /etc/lsb-release
file.
That's why my current strategy is:
1. Parse the de-facto-nearly-standard /etc/lsb-release file.
2. Ad-hoc techniques encoded into the Python Standard Library's
platform.dist().
3. Execute the de-jure-standard "lsb_release" in a subprocess.
4. Arch Linux
----------
_______________________________________
Python tracker <report at bugs.python.org>
<http://bugs.python.org/issue1322>
_______________________________________
More information about the Python-bugs-list
mailing list