[Dev] [Libretools - Bug #314] (open) have per-user staging dirs to support concurrent librerelease runs
fauno at kiwwwi.com.ar
Sun Apr 7 16:38:39 GMT 2013
Michał Masłowski <mtjm at mtjm.eu> writes:
>> what will happen when two concurrent db-update try to write the same
>> repo.db file, and one doesn't know the other modified it? you'll have
>> packages missing from repos but correctly released.
> Isn't this solved by locking the repos?
>> it would be better to make db-update ignore rsync tmp files on cleanup
> Doesn't rsync make each file non-tmp when it's complete before sending
> other files? It won't help in these cases, although I'm not sure now if
> they are possible.
so the problem is that alice has to upload 3 big packages, connection is
lost after 1.5 packages being uploaded, bob releases the first one
(db-update ignores the temp file) but alice doesn't notice because the
failed sync doesn't know it has to skip the first (it's not there
anymore so rsync uploads it) and continue from the second. the result
is alice uploading 3 packages again (if connection isn't lost) and the
first package being released twice, no?
i think it would be simpler to lock the stage area until all uploads are
done. this doesn't avoid the problem of packages being built by two or
more packagers, which is solved by coordination (!) and librerelease
checking if a package was already released. this would solve Alice
having to reupload a package and Bob missing Alice saying "i'll do
> Shouldn't this be discussed at labs.parabola.nu?
: the quickest way i can think of is checking if repo returns http
code 200 by requesting the headers for the file:
curl --head \
| head -n1 | cut -d" " -f2
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 489 bytes
Desc: not available
More information about the Dev