[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