Re: createrepo: external locking?

seth vidal <[email protected]> Wed, 25 Aug 2010 09:26:20 -0400
Newsgroups gmane.linux.rpm.metadata
Message-ID <1282742780.6822.76.camel@oliver>
On Wed, 2010-08-25 at 14:56 +0200, Oliver Hookins wrote:
> Hi all,
> 
> I've hit an interesting problem on some of our repositories we use for
> populating with our own applications. We have build servers generating RPMs
> automatically (sometimes on every scm commit) and these are then dumped into the
> yum repository directories and createrepo run on the directory to generate the
> metadata.
> 
> At the moment, this means that every job in the build system that generates RPMs
> must have its own directory (and now there are quite a few) as multiple
> createrepo instances running against the same directory fails. We can't just run
> it from cron periodically as there are some triggered jobs which pull down the
> most recent metadata immediately afterwards to do some testing of the new
> packages.
> 
> So, is there some way to get createrepo to lock a particular directory so that
> multiple processes can update the metadata at least sequentially? Or is this
> kind of thing best done with a wrapper around createrepo (or not at all)?
> 

I don't see how createrepo locking the dir would help unless all other
apps honored the locks quasi-sanely.

Is there a reason you cannot just make the program(s) which need to
access the metadata run in sequence and not in parallel?

-sv