"Maciej (Matchek) Bliziński" <[email protected]> writes: > 2013/7/20 Peter FELECAN <[email protected]>: >> "Maciej (Matchek) Bliziński" <[email protected]> writes: >> >>> 2013/7/20 Peter FELECAN <[email protected]> >>>> >>>> Look at what Debian has done to make the transition. They are not using >>>> specific 2.7 packages, the differentiation is 2 versus 3 which is >>>> understandable as there is an incompatibility between code written for 2 >>>> running in 3. >>> >>> I don't think they broke Python 2.6. Or did they? They have a special >>> mechanism for sharing modules between 2.6 and 2.7. >> >> Which is? Anyhow, they don't have the equivalent of CSWpy27-foo. A 2.x >> package is a 2.x package. > > 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 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. > - keep Python 3.x completely separate, with CSWpy33- package name prefix I agree. > The downside is that we're still using the bad site packages > directory. The upside is that this scenario meets all the basic > criteria: > - keep 2.6 working Why is that necessary in the long term? 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. > - easy to do Sure. The easiest would be to do nothing. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
