Zooko O'Whielacronx <zo...@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 <rep...@bugs.python.org> <http://bugs.python.org/issue1322> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com