No dia 14 de Outubro de 2010 03:24, Ben Walton <[email protected]> escreveu: > Excerpts from Philip Brown's message of Wed Oct 13 13:39:50 -0400 2010: > >> wait what? > >> we've been through this a few times. python files need to be >> compiled to a single, consistent place. Altering the dest with >> numerical revisions, has caused problems in the past. > > Ok, I'm looking at libxslt python handling right now and it goes to > great lengths to find a version numbered python site-packages and > includes directory. > > Looking at my debian box here, I have _only_ version suffixed > directories...there is no generic /usr/lib/python. > > $ ls -ld python* > drwxr-xr-x 21 root root 20480 2010-01-23 08:05 python2.5 > drwxr-xr-x 23 root root 20480 2010-04-30 07:24 python2.6 > drwxr-xr-x 28 root root 20480 2010-09-29 07:35 python3.1 > > Looking at current9x, we have /opt/csw/include/python (mostly empty) > and /opt/csw/include/python2.6 (the expected files). We then have > /opt/csw/lib/python2.6 (mostly empty) and /opt/csw/lib/python > (expected set of files). This is internally inconsistent. :( > > So, the question is, why are we _not_ shipping .py files in a version > specific site-packages area? Is this the general aversion to shipping > multiple python packages to support multiple version simultaneously? > > Given the landscape that I see out there, it looks to be logical to > ship a functional python2.5 (maybe not now), python2.6, python3.x, etc > that can co-exist. If we shipped a python 2.7 (for example only), > we'd have lib/python2.7, include/python2.7 and bin/python2.7 > (alternatives could provide the bin/python). > > This should make version upgrades of python less problematic for > modules that are built against $current_version. Similar to what > we're aiming to do with libraries, we could do with interpreters... > > Thoughts?
I agree with Ben. The Python file placement in CSWpython predates my involvement in the project, so I don't have any opinion on the problems that were happening in the past. I have some knowledge about what is the standard way of packaging Python, and what we're doing is not it. Each Python version requires the rebuild of all the modules. Here's a sketch of what packages could be named like: CSWpython (symlink only) CSWpython-devel (one devel package pointing at the newest Python) CSWpython26 (specific version of the interpreter) CSWpython27 (specific version of the interpreter) CSWpython31 (specific version of the interpreter) CSWlibpython2_5_1_0 (libpython for 2.5) CSWlibpython2_6_1_0 (libpython for 2.6) CSWpy26-foo (Python module for 2.6) CSWpy27-foo (Python module for 2.7) CSWpy31-foo (Python module for 3.1) _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
