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
