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 andymaier
Recipients andymaier, benjamin.peterson, berker.peksag, bgomes, christian.heimes, doko, draghuram, eric.araujo, georg.brandl, lemburg, pavel.vinogradov, pola, sapetnioc, vajrasky, vstinner, zooko
Date 2015-02-27.17:12:33
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1425057153.46.0.284717664556.issue1322@psf.upfronthosting.co.za>
In-reply-to
Content
Do we really think that a package on pypi solves the problem better? The discussion only shows that it is more likely we end up with multiple different packages on pypi, instead of one that is commonly agreed.

I agree it is tough to get to an agreed upon approach, but having this in the Python base at least ensures that it is the one approach everybody uses.

The /etc/os-release format seems to be used more often now, so I'm wondering why we cannot come up with a reasonable approach that is backwards compatible, supports /etc/os-release, and (if still needed), also /etc/lsb-release and the lsb_release script.

Again: If we ever want to end up with just one package on pypi, that very discussion needs to happen.

It seems to me that if the approach should be compatible, then we cannot use the new generic files (lsb* and os-release) first. The currently implemented approach needs to be used first. Then the new generic files.
History
Date User Action Args
2015-02-27 17:12:33andymaiersetrecipients: + andymaier, lemburg, georg.brandl, doko, zooko, vstinner, draghuram, christian.heimes, sapetnioc, benjamin.peterson, pavel.vinogradov, bgomes, eric.araujo, pola, berker.peksag, vajrasky
2015-02-27 17:12:33andymaiersetmessageid: <1425057153.46.0.284717664556.issue1322@psf.upfronthosting.co.za>
2015-02-27 17:12:33andymaierlinkissue1322 messages
2015-02-27 17:12:33andymaiercreate