<div dir="ltr"><br><div class="gmail_extra"><div class="gmail_quote">2013/8/1 Maciej (Matchek) Bliziński <span dir="ltr"><<a href="mailto:maciej@opencsw.org" target="_blank">maciej@opencsw.org</a>></span><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

<div><div class="h5">
>> One argument for keeping the CSWpy- prefix is that we start with one<br>
>> 2.x version (2.6) and we eventually want to end up with one 2.x<br>
>> version (2.7). When we go from 2.6 to 2.7, we can introduce the<br>
>> CSWpy27- packages, but there eventually would only be CSWpy27-<br>
>> packages and none of CSWpy-. I think that would be just annoyance for<br>
>> our users. If we can wiggle our way through from 2.6 into 2.7 without<br>
>> messing around with package names, it's better and smoother for our<br>
>> users.<br>
><br>
><br>
> I don't see this as a major annoyance. After all, users have to clean the<br>
> obsolete packages on their system, that is not something that is done<br>
> automatically when a package is dropped from the opencsw catalog.<br>
><br>
> One advantage for having a different prefix is that it will allow users to<br>
> keep their obsolete 2.6 python module on their system if they want to,<br>
> whereas if we have only one package CSWpy-, the day we decide to stop<br>
> shipping python 2.6, they will suddenly disappear.<br>
> This is not something we officially support, but I think this is nice for<br>
> users to know that once they installed or compiled something relying on a<br>
> opencsw library/module, they can be nearly sure it will work as long as they<br>
> don't remove the package.<br>
<br>
</div></div>We will need to kill Python 2.6 at some point. It probably won't be<br>
this year, but it eventually has to happen. We should focus on<br>
discussing when it will happen and how we'll handle it. We will<br>
probably keep Python 2.6 in one catalog release, and kill it in<br>
another. Users who want to stick with 2.6 will have the option of<br>
staying with an old catalog as long as they want.<br></blockquote><div><br></div><div style>Yes that's something we could say.</div><div style>We could also let users keep the old version of the package even if they are using a more recent catalog.</div>

<div style><br></div><div style>Thanks to having renamed libraries package based on their soname, that's something that is possible for libraries and I personnally think it's a good thing.</div><div style>For example, if someone compiled a binary against libssl0.9.8, they will not be forced to stick to an old catalog just because of that binary (a binary that might not even be recompiled against libssl1.0.0).</div>

<div style>They will be able to move on to a more recent catalog while keeping the obsolete libssl0.9.8 package installed.</div><div style><br></div><div style>I would think we could apply the same logic to python packages.</div>

<div style> <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<div class="im"><br>
> I personnally also like consistency. I didn't understand clearly how python<br>
> 3 modules will be handled. Will they all have a CSWpy33- prefix ? Will we<br>
> have the same kind of problem during upgrade or is the situation different<br>
> with python 3 ?<br>
<br>
</div>Python 3 is not backward compatible, so modules will live in a<br>
different place. The main question is whether we will make the module<br>
installation path specific to the minor version, or only to the major<br>
version. In other words, will it be /opt/csw/lib/python3.3 or<br>
something like /opt/csw/share/python3. Debian is doing the latter. We<br>
haven't really thought about Python 3 handling yet.<br></blockquote><div><br></div><div><br></div><div style>Ok, maybe we should try to include python 3 in the reflection to be sure it doesn't bring some new problem. This way we could define a consistent policy for Python.</div>

<div style><br></div><div style>If I understand well, we will prefix all python 3 modules with CSWpy33- our CSWpy3- ?</div><div style><br></div><div style>It seems for python 3, they tried to define a stable ABI / API subset: <a href="http://www.python.org/dev/peps/pep-0384/">http://www.python.org/dev/peps/pep-0384/</a><br>

</div><div style><br></div><div style>Yann</div><div><br></div><div><br></div><div> </div></div></div></div>