[arch-dev-public] devtools problem

[Allan McRae]

On 17/03/11 06:39, Pierre Schmitz wrote:
> 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?

find /var/lib/pacman/local -name depends

> I guess to solve the first problem we would
> also need a pacman-db-downgrade script.

pacman-db-downgrade would be basically impossible...  you could symlink 
the desc file to depends in every local package database directory.

Allan