On 05/07/2010 15:11, Allan McRae wrote:
Hi all,
Here comes a rebuild so large that our TODO list had trouble handling it! Hopefully all packages are now in the rebuild list.... At a total of 518 packages long, it puts the combined libpng/libjpeg rebuild to shame.
Geez...
Python-2.7 has been releases and will be the last 2.x official release of python. So it is time to switch to python-3.x as our /usr/bin/python and python-2.7 as our /usr/bin/python2. See http://wiki.archlinux.org/index.php/DeveloperWiki:Python_Todo_List for all the details about how to achieve this.
The wiki is very detailed but IMHO it would benefit from a short statement on the motivations for making the transition to Python 3 (possibly with some links to upstream regarding its status, stability, API changes, etc). just my 2¢...
It is actually not that hard. I had a system converted when python-3.1 was released as a test run. The main key is to build packages in a clean chroot so that they detect and point their files to /usr/bin/python2. Some packages are stupid and require a sed at the end of packaging to fix that.
Because this rebuild is crazy stupid, I would like to plan when it is going to occur. We will need to clear out [testing] as much as possible over the coming week or two (what is happening with perl...).
Re: perl in testing. No idea. I have updated the 'provides' array in the PKGBUILD for perl in trunk on May 26, and informed Kevin of the changes I made, but I have not heard from him since. I guess there were some issues preventing a move to core, but I don't know whether he has resolved them or not. I have not been able to help further. Preparing the new TeX Live packages takes all the time I can devote to Arch these days ;) But if everyone agrees that the package currently in testing is fine, I could rebuild it and move it to core, and move all other perl pkgs in testing/community-testing to extra or community.
Also, a new KDE is a the beginning of next month so I would not want to conflict with that. Any other major rebuilds on the way? Should we do this in a separate repo?
I think a separate repo is our best option. François