Title:		64-bit Python and removal of Python 2.3 from Nevada
Case:		PSARC/2006/666
Submitter:	Laszlo Peter
Owner:          John Fischer
Timeout:	12/08/2006 

1.0 Introduction

1.1 Project/Component Working Name:

    64-bit Python and removal of Python 2.3 from Nevada
    
1.2 Purpose

    This project includes:

    - delivering 64-bit Python interpreter, libraries and modules
      for Python 2.4: release binding: Patch
    - removing Python 2.3 from Solaris Nevada: release binding: Minor
    - fixing the /usr/sfw/bin/python symlink: release binding: Patch
    - changing the release binding of PSARC/2005/532 to Patch [1]
    
2.0 Description 

    2.0.1  Delivering 64-bit Python interpreter, libraries and modules

	   This is a requirement of the Xen project.  The project
	   delivers /usr/bin/{amd64,sparcv9}/python and
	   /usr/lib/64/libpython2.4.so.

	   Python bytecode (.pyc) and optimized bytecode (.pyo) objects
	   can be loaded by either variants.

	   Shared objects are duplicated as follows:

	   /path/to/python/module/foo.so     - 32-bit shared object
	   /path/to/python/module/64/foo.so  - 64-bit shared object

	   The project enhances python's distutils module so that
	   the shared objects are automatically installed in the
	   correct directory.

    2.0.2  Removing Python 2.3 from Solaris Nevada

	   Python 2.3 was declared Obsolete in PSARC/2005/532 [1]
	   It was left in /usr/sfw due to a slight risk of breakage
	   since the python bytecode files are not necessarily
	   compatible across python versions.  At this stage
	   Python 2.3 is getting old (Python 2.5 has been released
           recently).  All consumers of Python in Solaris (Xen, Orca,
           JDS) use Python 2.4.  It is very likely that customers
           also migrated to Python 2.4.

    2.0.3  Fixing the /usr/sfw/bin/python symlink

           In PSARC/2005/532 it was decided that /usr/sfw/bin/python
	   should point to /usr/bin/python2.4, however in retrospect
	   that was a mistake as it defeats the purpose of this
           symlink (i.e. apps that depend on python2.3 can continue
           to use /usr/sfw/bin/python), furthermore
           /usr/sfw/bin/python2.3 was never defined as an interface
	   so apps that may depend on python2.3 would have to be
	   changed to use an unclassified interface.

	   This project changes /usr/sfw/bin/python as follows:

	   in S10: /usr/sfw/bin/python -> python2.3
	   in S11: /usr/sfw/bin/python -> ../../bin/python2.4

    2.0.4  Changing the release binding of PSARC/2005/532

	   This is a request to deliver python 2.4 (32 and 64-bit
	   versions) into a patch release of Solaris.  This is a
	   requirement of the Xen project.

2.2 Interface Changes

	   Interface               Classification  Comments
	   ---------------------   --------------  ----------------------
	   /usr/sfw/bin/python     Obsolete        points to python2.3 on
						   Solaris 10
						   points to python2.4 on
						   Solaris Nevada

	   /usr/bin/amd64/python   Volatile        (new)
	   /usr/bin/sparcv9/python Volatile        (new)

	   /usr/lib/amd64/         Volatile        (new)
		libpython2.4.so
	   /usr/lib/sparcv9/       Volatile        (new)
		libpython2.4.so

3.0 Packaging Python modules

    The following is advice to potential consumers of Python.

    Python modules have 3 incarnations:
     - foo.py:  python sources
     - foo.pyc: python compiled bytecode
     - foo.pyo: python optimized bytecode

    At this point, there is hardly any difference between .pyc and .pyo
    so the advice is to ship both .py and .pyc, but not .pyo.

    As highlighted by "6469243 Python has quantum observability problems",
    Python records the mtime of the py file in .pyc file.  When importing
    the .pyc file, it checks that the recorded and the real mtime are
    equal.  If not, it recompiles the .py file and, if the permissions
    allow it, writes a new .pyc file.  Therefore, importing a .pyc file
    with an incorrect mtime will result in changing files in the filesystem,
    causing pkgchk errors.   Packagers of Python module need to be aware
    of this behaviour and make sure that mtimes are preserved, either by:

    - not copying or modifying the files
    - restoring the mtime after copying (e.g. touch -r src dest);
      an alternative is to use compileall

    Finally, a reminder that as per PSARC/2005/555, python modules
    shipped in Solaris must be installed in
        /usr/lib/python<version>/vendor-packages
    as opposed to the default
        /usr/lib/python<version>/site-packages
    directory.

4.0 References

    1. http://sac.sfbay/PSARC/2005/532  Python migration from /usr/sfw
       to /usr and upgrade to v2.4.x
    2. http://sac.sfbay/PSARC/2005/555  Python "vendor-packages" support
    3. http://sac.sfbay/LSARC/2005/504  Orca Screen Reader/Magnifier for
       the JDS desktop
    4. http://sac.sfbay/PSARC/2006/260  Solaris on Xen