I spent a good amount of effort last fall on 2.7 packaging. I have working packages and rebuilt a pile of modules... I just didn't get all the way through the stack. There is a wiki page tracking the process.
This could be dusted off with little effort. The module directory needs to be versions. Madness lies in the other direction. :) Thanks -Ben On Jul 18, 2013 5:07 PM, "Maciej (Matchek) Bliziński" <[email protected]> wrote: > 2013/7/18 Peter FELECAN <[email protected]>: > > "Maciej (Matchek) Bliziński" <[email protected]> writes: > >> When that's done, let's discuss what do we want to do about Python > >> 2.7. Peter's concern is that if we keep the versioned directory, it > >> will be hard to transition to 2.7. Peter's objective is to package > >> calibre, which needs Python 2.7 and a number of modules. I suggest > >> that we build Python 2.7 as it was before r21514, in a versioned > >> directory, and we build the necessary modules as CSWpy27-foo. > > > > Naming the new packages CSWpy27-xxx is not a good idea from my > > standpoint. What I propose is when we rebuild a Python module package we > > just use the previous name and have a dependency on CSWpython27. > > This will break the 2.6 world. In your scenario: > > Before: > CSWpython (which is Python 2.6) > CSWpy-foo (built into the unversioned directory) > > #!/opt/csw/bin/python2.6 > import foo # works > > After: > CSWpython (which is Python 2.6) > CSWpython27 > CSWpy-foo (built into the 2.7 versioned directory) > > #!/opt/csw/bin/python2.6 > import foo # fails > > > Also, we should release a new 2.6 package where the /opt/csw/bin/python > > path doesn't exist anymore such as the default Python interpreter will > > be 2.7. > > /opt/csw/bin/python should be a symlink driven by alternatives. We > need to think what should be the default if both 2.6 and 2.7 Pythons > are installed. I'm thinking that 2.6 should be the default for now. > > >> Maybe we could patch Python 2.7 to look into the unversioned directory > >> for modules - as a backup solution. But we would need to see if this > >> would break anything or not. > > > > It breaks the building of Python 2.7 itself as it will mess with shared > > objects provided by Python 2.6 which are stored in the unversioned > > tree. If there is a way to make Python's byzantine build system to not > > look for shared objects in that path then everything is fine. > > So why not simply let Python do its thing, where 2.6 is isolated from > 2.7? This is the way it works out of the box. You just build stuff you > need for 2.7 a and you're done. > > Maciej > _______________________________________________ > maintainers mailing list > [email protected] > https://lists.opencsw.org/mailman/listinfo/maintainers > .:: This mailing list's archive is public. ::.
_______________________________________________ maintainers mailing list [email protected] https://lists.opencsw.org/mailman/listinfo/maintainers .:: This mailing list's archive is public. ::.
