On Wed, 16 Mar 2011 22:30:47 +0200, Ionuț Bîru wrote:
On 03/16/2011 09:27 PM, Pierre Schmitz wrote:
On Wed, 16 Mar 2011 13:46:21 -0500, Dan McGee wrote:
Multiple signoffs per architecture would be great, as well as any observations dealing with the upgrade process. Release notes: http://projects.archlinux.org/pacman.git/tree/NEWS
Thanks to everybody involved!
I'll give my signoff after I was able to do some more testing. The upgrade itself went fine. (I also checked the case when not running pacman-db-upgrade and running it twice) Everybody using our devtools will need to either manually run that or simply recreate the chroot env using the -c switch.
if all were that simple...
right now all chroots for staging/testing are broken on our build system because they would be recreated using _system_ pacman (old database format) and there isn't any way to run pacman-db-upgrade.
if system pacman is updated to 3.5 then you can't create new extra-x86_64/i686 chroots because it would use the new database inside and pacman 3.4 is unable to use.
to tackle this problem, this should be fixed in devtools and run pacman-db-upgrade automatically after a pacman update.
You are right, I missed that. I have no idea how to fix the testing host with extra chroot problem. Is there a way to detect when running pacman-db-upgrade is needed? I guess to solve the first problem we would also need a pacman-db-downgrade script. The cleanest way would probably to not use the host pacman but do some kind of bootstrap. Any input on this is welcome; haven't really thought about that yet. -- Pierre Schmitz, https://users.archlinux.de/~pierre