Stef Walter s...@memberwebs.com added the comment:
Good plan.
So the issue is:
* Platform specific eggs are built containing a path that has the full
patch level of the freebsd kernel, like 8.2-RELEASE-p2. The -p2
part is updated for every security patch of FreeBSD.
* Thus when you
Stef Walter s...@memberwebs.com added the comment:
Shrug. I guess you can close it.
This is still a bothersome issue, but we've taken to patching every version of
python downstream before deploying them. All for a simple three line patch
Stef Walter s...@memberwebs.com added the comment:
I agree with your comments, and the solution you're proposing solves the
problem (and several others) for the long term.
However in the short term, could this patch be committed? Most other OS's
(including openbsd and netbsd) have OS
Stef Walter s...@memberwebs.com added the comment:
Other OSs have special cases in get_platform() to specifically limit the
amount of code, and make proper decisions with regard to package
compatibility.
Here's an example this commit for Mac OS X: http://svn.python.org/view?
view=revrevision
Stef Walter s...@memberwebs.com added the comment:
Marc-Andre Lemburg wrote:
Is that binary compatibility scheme documented somewhere ?
Not sure, it's been referred to and adhered to many times in the FreeBSD
community, but I'm not sure where it's documented. I'll ask around on
the FreeBSD
Stef Walter s...@memberwebs.com added the comment:
About FreeBSD ABI compatibility between minor versions:
Julian Elischer wrote:
It is a policy of the project but I don't think our policies are
written down as such. I think you will find it referenced in
many places in a sideways manner
New submission from Stef Walter s...@memberwebs.com:
In Lib/distutils/util.py in the get_platform() function there's OS
specific code to create a string which describes the current platform.
This usually includes the OS + version + arch.
FreeBSD specific code is missing from this function
