[arch-dev-public] devtools problem

Pierre Schmitz pierre at archlinux.de
Wed Mar 16 16:39:12 EDT 2011


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


More information about the arch-dev-public mailing list