This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author lemburg
Recipients benjamin.peterson, bgomes, christian.heimes, draghuram, georg.brandl, lemburg, pavel.vinogradov, sapetnioc, zooko
Date 2008-09-23.20:05:22
SpamBayes Score 3.53165e-11
Marked as misclassified No
Message-id <48D94C01.5010800@egenix.com>
In-reply-to <1222199344.59.0.624095734142.issue1322@psf.upfronthosting.co.za>
Content
On 2008-09-23 21:49, Zooko O'Whielacronx wrote:
> Zooko O'Whielacronx <zooko@zooko.com> added the comment:
> 
> MAL:  why do you say it is better to look for
> /etc/$supportedplatform-release files first instead of looking for
> /etc/lsb-release first?

Because that's exactly what lsb_release does as well. The data
in /etc/lsb-release can only override data already parsed from
the /etc/<distro>-release file.

> I do not know if /etc/lsb-release is suitably generic -- I've tried it
> only on a few platforms.  I do know that executing lsb_release is
> suitably generic since it is standard, but I prefer not to try it first
> since it imposes about half-a-second delay.

lsb_release is standard on LSB compliant Linuxes, but the much
older /etc/<distro>-release file approach is still valid and in
wide use.

E.g. on SuSE, /etc/lsb-release doesn't contain any usable
distribution information. On Fedora, that file doesn't exist at
all.

It's better to follow the approach taken by lsb_release and then
add calling lsb_release as one of the methods taken by
_dist_try_harder() (using platform.popen()) should the parsers
fail.

This avoids spawning a process in most cases.
History
Date User Action Args
2008-09-23 20:05:24lemburgsetrecipients: + lemburg, georg.brandl, zooko, draghuram, christian.heimes, sapetnioc, benjamin.peterson, pavel.vinogradov, bgomes
2008-09-23 20:05:23lemburglinkissue1322 messages
2008-09-23 20:05:22lemburgcreate