Yeah, apparently there are versions of the rpm command that are buggy at the
db-locking step...for instance, on RHEL3.
As far as doing the install action, sometimes this is pretty hard to avoid,
since you may need to use an rpm as a compile-time dependency for another
project in the reactor. In the case of C code, it'll need those files to be
in place on the system for that second compile to work...requiring
installation, effectively.
-john
On 1/31/07, Bob Allison <[EMAIL PROTECTED]> wrote:
The RPM plugin I wrote in Codehaus uses a subdirectory of
"${basedir}/target" as the place where everything to be packaged is
assembled. This should mean that the _BUILD_ of an RPM can run in
parallel
with another _BUILD_.
It is always going to be bad form to try to do multiple _INSTALL_ actions
in
parallel. Usually, the RPM command line tool will detect that the
database
is locked (since step one in doing an install is to lock the database so
you
can update it); I can easily see some race conditions where this might not
always work.
HTH
----- Original Message -----
From: "John Casey" <[EMAIL PROTECTED]>
To: "Maven Developers List" <[email protected]>
Sent: Wednesday, January 31, 2007 2:37 PM
Subject: Re: Using maven to build RPMs and problems with the RPM database
> Concurrency is an issue any way you slice it, and it's not just limited
to
> RPMs. RPMs represent a set of files installed on the system, so you have
> to
> somehow verify that you're not installing the same RPM _or_file_list_ on
> one
> system at the same time. Granted, this isn't as severe a limitation as
the
> concurrent modification problem in the rpm database, but it's still an
> important factor.
>
> So, if a dev team is sharing a machine and needs to do concurrent
> build/installs - or, in CI situations where a similar thing is happening
-
> it might be essential to setup some sort of chroot setup with a separate
> rpm
> database for each, so the filesystem paths don't overwrite. This is a
BIG
> thing to tackle in any sort of universal way, and I'm not even going to
> pretend to understand all that would be involved...only that it's much
> more
> than just dealing with the RPM database.
>
> It's not arbitrary classpaths out here, and we're not in Kansas anymore.
> :-)
>
> -john
>
> On 1/31/07, Jason van Zyl <[EMAIL PROTECTED]> wrote:
>>
>> Hi,
>>
>> I'm just throwing out a question because I have experience a problem
>> with concurrency in the RPM database. Over in the CBUILDs stuff where
>> we are using Maven to build RPMs whenever I do two simultaneous
>> builds where the result is installing an RPM I seem to corrupt the
>> database rendering RPM useless without rebuilding the RPM database.
>> I've read in some places that you cannot run RPM commands in parallel
>> because of concurrency issues. I'm locked to RHEL 3. If there was a
>> locking mechanism I suppose that would be someone better but means
>> all my builds are going to block on the lock. But if there are
>> concurrency issues that means trying to build RPMs during a
>> development is impractical. Anyone have a definitive answer on this
>> or a pointer to some documentation? I'm going to try and contact Erik
>> Troan for a definitive answer but if anyone knows please pipe up! :-)
>>
>> Jason.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
