2013/7/20 Peter FELECAN <[email protected]>: >> The Debian policy discusses 2.5 vs 2.6, but it's the same discussion. >> >> http://www.debian.org/doc/packaging-manuals/python-policy/ch-python.html >> >> "A common location to share, across Python versions, arch-independent >> files which would otherwise go to the directory of system public >> modules is /usr/share/pyshared." > > We can introduce this kind of location if we wish; I'm not being so warm > toward that but why not.
I'm not saying that this is what we should do; but I'm saying that that's what Debian is doing to share modules between 2.x Python versions. >>>>> I would like to be understood that what I'm aiming at is 2 pronged: >>>>> >>>>> 1. minimal investment >>>>> 2. fastest turn around >>>> >>>> With Python 2.6 being expendable? >>> >>> Why do you think so? >>> >>> In my current endeavor, I come to realize that our Python eco-system is >>> brain damaged. >>> >>> What I propose is not to lobotomize, but to have brain surgery. >> >> A plan that could work, is the following: >> >> - rebuild 2.6 with /opt/csw/bin/python controlled by the alternatives system >> - build 2.7 as you did, with /opt/csw/lib/python/site-packages as an >> extra module search path, and with /opt/csw/bin/python also controlled >> by alternatives > > Why alternatives when we wish to make a transition from 2.6 to 2.7? > > In my proposition we would have python -> python2 -> python2.7 and > python2.6 is there for those really needing it, which can put in their > scripts #! /opt/csw/bin/python2.6 > >> - keep using the CSWpy- package name prefix > > Alright > >> - keep building 2.x modules with Python 2.6 only; never build modules >> with 2.7 and never put them into the >> /opt/csw/lib/python2.7/site-packages directory > > Why's that? This precludes a transition. Does it? When you have python2.7 looking for modules in the /opt/csw/lib/python/site-packages (unversioned) directory, and you make /opt/csw/bin/python2.7 the higher priority alternative, you can install Python 2.6 and everything will work. You can install Python 2.7 and everything will work too. You've transitioned already, no? >> - keep 2.6 working > > Why is that necessary in the long term? Our users will migrate from 2.6 into 2.7 at a different point in time that we do. We must first provide a package catalog in which both 2.6 and 2.7 versions work. Then our users will take their time and update their installations, and their Python-dependent software. We can use our release cycle to deprecate Python 2.6, but there still must be an overlap. > Anyhow, I don't get why we > cannot do this in the unstable catalog. Support for 2.7 and associated > eco-system should be a transition criteria from unstable to the next to > next stable / named catalog. Unstable is unstable... but preferably not so unstable that Python doesn't work any more. If we want to perform a grand rebuild, we have the beanie catalog specifically for this kind of work. Maciej _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
