[csw-maintainers] Python 2.7

Peter FELECAN pfelecan at opencsw.org
Thu Aug 1 10:42:17 CEST 2013

Yann Rouillard <yann at pleiades.fr.eu.org> writes:

> 2013/8/1 Maciej (Matchek) Bliziński <maciej at opencsw.org>
>> 2013/7/31 Dagobert Michelsen <dam at opencsw.org>
>> > I followed the discussion on cross-version modules and the more I think
>> about it
>> > the more I think it would be better to clearly separate modules for
>> different
>> > Python versions. If you already built them with modulations I don't see
>> the
>> > point in putting them all in one package instead of having the old (2.6)
>> > CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible
>> benefit
>> > I see is that people who are using 2.6 can pkgutil update and switch to
>> 2.7
>> > after all has been rebuilt. But that can be achieved with a online
>> shellscript
>> > installing CSWpy27- for all CSWpy- modules.
>> One argument for keeping the CSWpy- prefix is that we start with one
>> 2.x version (2.6) and we eventually want to end up with one 2.x
>> version (2.7). When we go from 2.6 to 2.7, we can introduce the
>> CSWpy27- packages, but there eventually would only be CSWpy27-
>> packages and none of CSWpy-. I think that would be just annoyance for
>> our users. If we can wiggle our way through from 2.6 into 2.7 without
>> messing around with package names, it's better and smoother for our
>> users.
> I don't see this as a major annoyance. After all, users have to clean the
> obsolete packages on their system, that is not something that is done
> automatically when a package is dropped from the opencsw catalog.
> One advantage for having a different prefix is that it will allow users to
> keep their obsolete 2.6 python module on their system if they want to,
> whereas if we have only one package CSWpy-, the day we decide to stop
> shipping python 2.6, they will suddenly disappear.
> This is not something we officially support, but I think this is nice for
> users to know that once they installed or compiled something relying on a
> opencsw library/module, they can be nearly sure it will work as long as
> they don't remove the package.
> I personnally also like consistency. I didn't understand clearly how python
> 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we
> have the same kind of problem during upgrade or is the situation different
> with python 3 ?

What people need to understand is that a 2.6 non binary module can be
run by a 2.7 interpreter. The reverse is not always true. This is why I
proposed to replace 2.6 by 2.7 in our next transition from unstable to a
named catalog.

This is not to be confused with the major incompatibilities between 2.x
and 3.x where using a different prefix is required.


More information about the maintainers mailing list