"Maciej (Matchek) Bliziński" <[email protected]> writes: > 2013/8/1 Yann Rouillard <[email protected]>: >> >> 2013/8/1 Maciej (Matchek) Bliziński <[email protected]> >> >>> 2013/7/31 Dagobert Michelsen <[email protected]> >>> > 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. > > We will need to kill Python 2.6 at some point. It probably won't be > this year, but it eventually has to happen. We should focus on > discussing when it will happen and how we'll handle it. We will > probably keep Python 2.6 in one catalog release, and kill it in > another. Users who want to stick with 2.6 will have the option of > staying with an old catalog as long as they want. > >> 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 ? > > Python 3 is not backward compatible, so modules will live in a > different place. The main question is whether we will make the module > installation path specific to the minor version, or only to the major > version. In other words, will it be /opt/csw/lib/python3.3 or > something like /opt/csw/share/python3. Debian is doing the latter. We > haven't really thought about Python 3 handling yet.
Of course is the path as is orthogonal with 2.x path. >>> I'm curious if anyone will object to my idea to drop the dependency on >>> the interpreter. >> >> >> The implicit contract is that when you pkgutil -i something, everything will >> be installed so that it will work properly. >> That being said, I don't think this is as big problem because: >> - if a user manually installs a module, he is supposed to know that a >> python module needs python and have probably already installed python, >> - if a python program need a python module, he also needs for itself the >> python interpreter so there is no dependency problem. >> >> I think this would be a compromise considering the fact that we don't have a >> dependency system with virtual dependency (where we can say that a package >> depends on any python interpreter < 3 and >= 2.6) > > That's my thinking as well. Unless anyone objects, I'll make it happen soon. As told before, I object. -- Peter _______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
