[arch-dev-public] Time to go forward with arch=any?

Firmicus Firmicus at gmx.net
Wed Jul 22 09:01:56 EDT 2009


Aaron Griffin a écrit :
> On Tue, Jul 21, 2009 at 5:25 PM, Firmicus<Firmicus at gmx.net> wrote:
>   
>> Added some output to the lock/unlock functions to see if it helps
>> illustrate the issue better
>>
>> I also fiddled with the cleanup function in db-update a bit, so it
>> only calls repo_unlock on an error. Didnt commit the changes, but lets
>> see if that helps
>>
>>
>>
>> I think I fixed it. The thing is that through
>>     trap cleanup 0
>> the function cleanup() is called automatically at the end of the script.
>> And since cleanup in turn calls
>>     repo_unlock $reponame $current_arch
>> the latter fails because $current_arch is "x86_64" and we have already
>> unlocked each repo before the end of the for loop, resulting in a spurious
>> error message.
>> Replacing repo_unlock by
>>     rm -f $TMPDIR/.repolock.$reponame.*
>> in cleanup() solves this. (It might be actually better to have a function
>> delete_repolocks() in db-function that does this...)
>>     
>
> Actually, the point of repo_lock/unlock was to do just this. The
> problem with this change is that repo_lock, in theory, may not always
> make a file like that (we may decide, at a later date, to "lock" the
> repo some different way). The lock/unlock pairs should be done on each
> repo, and needs to be there for the error case.
>   

I perfectly agree on that.

> I made a change to simply remove the trap after the looping is done.
>   
Fine.

> I'll commit the rest of the patch too
>
>   
Thanks.

The scripts now work flawlessly :)

I think you can now safely remove the DBG messages from db-functions.

F



More information about the arch-dev-public mailing list