[arch-dev-public] Python-3.x transition with python-2.7 update
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. 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. 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...). 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? Allan
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
On 05/07/10 23: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.
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.
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...). 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?
Just to clarify why this _is_ happening. python-2.7 will enable USC4 (UTF8) and will not enable the usual stupid hack of including the previous pythons include path (the past has shown that this breaks too much). So ~500 out of the 518 packages are going to need to be rebuilt anyway... I think this is a major point people are missing. So the choice is: 1) massive rebuild now _and_ even more massive rebuild later when python3 is more widely used with lots of package renames (python3-foo would need renamed python-foo and python-foo would become python2-foo). We actually can not handle that dual rename with provides/replaces/conflicts.... 2) one massive rebuild allowing the packages to gradually transition their packages to python3. As in the wiki, there will be no forced package renaming (let the maintainers introduce a python2-foo package only if they want to supply a python2 and python3 version) but the description should be updated to say python2. #1 is completely crazy and can not be done cleanly on a rolling release distro. #2 is slightly crazy and works fine (one of my installs underwent this conversion). This has been in planning for over a year. I have trialled various ways of achieving this transition over the last year and have concluded that doing it with the python-2.7 release is optimal because: - we are doing most of the rebuilds anyway - it is early enough that our repo is not filled with python3-foo packages - most major python projects have basic python3 support in their developmental code or are working on it (see the number of GSoC projects doing this transition....) so we will see python3 packages soon. I am not delaying the inevitable, especially when the delay will hurt us more in the long run. Allan
On 05/07/10 23:11, Allan McRae wrote: <snip>
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...). 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?
Well, no-one has mentioned anything... I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running? It will also happen to correspond with the release of this awesome python 3 book: https://www.packtpub.com/python-3-object-oriented-programming/book . (Hi Dusty!) Does this sound reasonable to everyone or have I missed a major release that this will block? Allan
On Thu, 08 Jul 2010 10:56:39 +1000, Allan McRae <allan@archlinux.org> wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
I would like to implement that...but I am really unsure if people want me to or not. Also we should try to get the package pool running before as we would benefit a lot from this for such large rebuilds. But I am quite sure I should have the final patches for dbscripts done by then. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On 08/07/10 18:34, Pierre Schmitz wrote:
On Thu, 08 Jul 2010 10:56:39 +1000, Allan McRae<allan@archlinux.org> wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
I would like to implement that...but I am really unsure if people want me to or not.
I say go ahead and do it. I work on the principle that if no-one speaks out against it, then it is a good idea...
Also we should try to get the package pool running before as we would benefit a lot from this for such large rebuilds. But I am quite sure I should have the final patches for dbscripts done by then.
Hopefully. This is a rebuild that would really benefit from that. Allan
On Thu, Jul 8, 2010 at 5:35 AM, Allan McRae <allan@archlinux.org> wrote:
On 08/07/10 18:34, Pierre Schmitz wrote:
On Thu, 08 Jul 2010 10:56:39 +1000, Allan McRae<allan@archlinux.org> wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
I would like to implement that...but I am really unsure if people want me to or not.
I say go ahead and do it. I work on the principle that if no-one speaks out against it, then it is a good idea...
I'll speak out against it- not super strongly, but still a -1. We had an unstable repo for ages and it was completely underused. Now we are establishing another repo that will probably always have to be enabled in lockstep with [testing] anyway. I guess I just think we could use [testing] more effectively rather than adding some new [staging] repo. -Dan
On Thu, 8 Jul 2010 07:25:32 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jul 8, 2010 at 5:35 AM, Allan McRae <allan@archlinux.org> wrote:
On 08/07/10 18:34, Pierre Schmitz wrote:
On Thu, 08 Jul 2010 10:56:39 +1000, Allan McRae<allan@archlinux.org> wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
I would like to implement that...but I am really unsure if people want me to or not.
I say go ahead and do it. I work on the principle that if no-one speaks out against it, then it is a good idea...
I'll speak out against it- not super strongly, but still a -1. We had an unstable repo for ages and it was completely underused. Now we are establishing another repo that will probably always have to be enabled in lockstep with [testing] anyway. I guess I just think we could use [testing] more effectively rather than adding some new [staging] repo.
Please reread my proposal. It's completely different from the unstable repo and also includes a new policy for testing. Anyway; this wont work at all if not everybody will use it and just use testing as we do now. So for now I wont waste time on this idea as long as there was no decision. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Thu, Jul 8, 2010 at 7:30 AM, Pierre Schmitz <pierre@archlinux.de> wrote:
On Thu, 8 Jul 2010 07:25:32 -0500, Dan McGee <dpmcgee@gmail.com> wrote:
On Thu, Jul 8, 2010 at 5:35 AM, Allan McRae <allan@archlinux.org> wrote:
On 08/07/10 18:34, Pierre Schmitz wrote:
On Thu, 08 Jul 2010 10:56:39 +1000, Allan McRae<allan@archlinux.org> wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
I would like to implement that...but I am really unsure if people want me to or not.
I say go ahead and do it. I work on the principle that if no-one speaks out against it, then it is a good idea...
I'll speak out against it- not super strongly, but still a -1. We had an unstable repo for ages and it was completely underused. Now we are establishing another repo that will probably always have to be enabled in lockstep with [testing] anyway. I guess I just think we could use [testing] more effectively rather than adding some new [staging] repo.
Please reread my proposal. It's completely different from the unstable repo and also includes a new policy for testing. Anyway; this wont work at all if not everybody will use it and just use testing as we do now. So for now I wont waste time on this idea as long as there was no decision.
Yes, part of the reason I hadn't responded before was that I didn't have time to read it back then, and it had slipped my mind. I will read it and attempt to give you more constructive feedback. -Dan
On 07/08/2010 03:56 AM, Allan McRae wrote:
On 05/07/10 23:11, Allan McRae wrote: <snip>
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...). 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?
Well, no-one has mentioned anything...
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
i'm fine with this. you seems to have planned this massive rebuild very well and i trust your judgment. -- Ionuț
On Thursday 08 July 2010 02:56:39 Allan McRae wrote:
Well, no-one has mentioned anything... Sorry, but I've really few free time in these days.
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running? 9th August is fine for me. KDE should be released 4th, give me a couple of days and I'll put it in [testing] for someday, then I will move it out and we can start the build. Or we can use the [staging] repo and keep KDE in [testing] for a week. Anyway the RC1 is enough stable and this RC2 is still better; I could upload the RC2 in [testing] today and the stable release directly in [extra].
-- andreascarpino.it Arch Linux Developer
On Thu, 8 Jul 2010 13:41:21 +0200, Andrea Scarpino <andrea@archlinux.org> wrote:
On Thursday 08 July 2010 02:56:39 Allan McRae wrote:
Well, no-one has mentioned anything... Sorry, but I've really few free time in these days.
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running? 9th August is fine for me. KDE should be released 4th, give me a couple of days and I'll put it in [testing] for someday, then I will move it out and we can start the build. Or we can use the [staging] repo and keep KDE in [testing] for a week. Anyway the RC1 is enough stable and this RC2 is still better; I could upload the RC2 in [testing] today and the stable release directly in [extra].
Imho testing should only contain candidates for extra. And I guess as you wouldn't push an rc to extra you shouldn't put it into testing either. -- Pierre Schmitz, https://users.archlinux.de/~pierre
On Thu, Jul 8, 2010 at 1:41 PM, Andrea Scarpino <andrea@archlinux.org> wrote:
On Thursday 08 July 2010 02:56:39 Allan McRae wrote:
Well, no-one has mentioned anything... Sorry, but I've really few free time in these days.
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running? 9th August is fine for me. KDE should be released 4th, give me a couple of days and I'll put it in [testing] for someday, then I will move it out and we can start the build. Or we can use the [staging] repo and keep KDE in [testing] for a week. Anyway the RC1 is enough stable and this RC2 is still better; I could upload the RC2 in [testing] today and the stable release directly in [extra].
-- andreascarpino.it Arch Linux Developer
fyi, we should probably delay the python upgrade a bit as kde 4.5 has been retagged and postponed to August 10th. Ronald
On 05/08/10 05:35, Ronald van Haren wrote:
On Thu, Jul 8, 2010 at 1:41 PM, Andrea Scarpino<andrea@archlinux.org> wrote:
On Thursday 08 July 2010 02:56:39 Allan McRae wrote:
Well, no-one has mentioned anything... Sorry, but I've really few free time in these days.
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running? 9th August is fine for me. KDE should be released 4th, give me a couple of days and I'll put it in [testing] for someday, then I will move it out and we can start the build. Or we can use the [staging] repo and keep KDE in [testing] for a week. Anyway the RC1 is enough stable and this RC2 is still better; I could upload the RC2 in [testing] today and the stable release directly in [extra].
-- andreascarpino.it Arch Linux Developer
fyi, we should probably delay the python upgrade a bit as kde 4.5 has been retagged and postponed to August 10th.
That is fine. I have some toolchain fun to do in the meantime! :) I will have the python{,2} packages prepared to push the moment this moves to [extra]. Allan
On Thu, 2010-07-08 at 10:56 +1000, Allan McRae wrote:
I will schedule this for the week starting August the 9th. This is after the KDE 4.5 release but before the first beta for GNOME 3.0. It will also give us plenty of time to clean out [testing] and perhaps get that [staging] repo running?
As for GNOME 3.0: that isn't going to happen. Upstream decided to delay GNOME 3.0 to next year and make a GNOME 2.32 with lots of things wrecked out. Basically, GNOME 2.32 is just 2.30 with bugfixes and string/UI breaks. I don't even think that will go through testing if I take a look at expected changes.
participants (8)
-
Allan McRae
-
Andrea Scarpino
-
Dan McGee
-
Firmicus
-
Ionuț Bîru
-
Jan de Groot
-
Pierre Schmitz
-
Ronald van Haren