<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><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

<div class="im">2013/7/31 Dagobert Michelsen <<a href="mailto:dam@opencsw.org">dam@opencsw.org</a>><br>
> I followed the discussion on cross-version modules and the more I think about it<br>
> the more I think it would be better to clearly separate modules for different<br>
> Python versions. If you already built them with modulations I don't see the<br>
> point in putting them all in one package instead of having the old (2.6)<br>
> CSWpy- and the new CSWpy27- and CSWpy33- modules. The only possible benefit<br>
> I see is that people who are using 2.6 can pkgutil update and switch to 2.7<br>
> after all has been rebuilt. But that can be achieved with a online shellscript<br>
> installing CSWpy27- for all CSWpy- modules.<br>
<br>
</div>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></blockquote><div><br></div><div style>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.<br>

</div><div style><br></div><div style>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.</div>

<div style>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.</div>

<div style><br></div><div style>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 ?</div>

<div style><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I'm curious if anyone will object to my idea to drop the dependency on<br>
the interpreter.<br></blockquote><div><br></div><div style>The implicit contract is that when you pkgutil -i something, everything will be installed so that it will work properly.</div><div style>That being said, I don't think this is as big problem because:</div>

<div style>  - if a user manually installs a module, he is supposed to know that a python module needs python and have probably already installed python,</div><div style>  - if a python program need a python module, he also needs for itself the python interpreter so there is no dependency problem.</div>

<div style><br></div><div style>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)</div>

<div style><br></div><div style>Yann</div><div><br></div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Maciej<br>
</font></span><div class="HOEnZb"><div class="h5">_______________________________________________<br>
maintainers mailing list<br>
<a href="mailto:maintainers@lists.opencsw.org">maintainers@lists.opencsw.org</a><br>
<a href="https://lists.opencsw.org/mailman/listinfo/maintainers" target="_blank">https://lists.opencsw.org/mailman/listinfo/maintainers</a><br>
.:: This mailing list's archive is public. ::.<br>
</div></div></blockquote></div><br></div></div>