Re: --retry <num> and --sleeptime <num>

[Jeff Johnson <jbj JBJ ORG>]

On Fri, Jul 20, 2001 at 02:59:31PM +0200, Peter A Jonsson wrote:
> Hello,
> 
> attached patch gives the options --retry <num> and --sleeptime <num> to rpm 
> when installing/upgrading packages (-i/-U). My way of testing was to run rpm 
> -i bigpackage.rpm and press ^Z, after that trying rpm -i anotherpackage.rpm 
> and seeing it retry. The default for sleeptime and retries is 0.
> 

Hmmm, another rpm hacker. Thanks for the patch!

There's a better way IMHO. The Berkeley DB permits a CDB model
(Concurrent DataBase) that has finer grained locking than the exclusive
lock traditionally used by rpm. I know that CDB works fine for the rpmdb, but
other mechanisms are gonna be needed to synchronize rpm install operations that
currently implicitly assume that an exclusive lock on the database provides
a mutex. Anyways a CDB model will permit concurrent access from, say, an
rpm query run from a %post scriptlet, and should remove the need to
sleep while waiting for an exclusive lock.

> I needed to pass more parameters to rpmInstall(). The (ugly) fix of this was 
> to rename rpmInstall() to rpm_Install() and define a macro named rpmInstall() 
> which called rpm_Install() with the correct number of parameters. This should 
> not break backwards compability with other programs. Should it be done in some 
> other way?
> 

There's nothing other than rpm that calls rpmInstall() that I'm aware of.
Meanwhile, that interface is changing anyways in rpm-4.0.3, as rpm install
and erase modes need to be merged into a common routine. The new args will look
much more like the rpmQuery()/rpmVerify() interface when I'm done.

> The possible use of it is if several machines need to access the same database 
> at once. The one that does not get the lock will sleep for the amount of 
> seconds specified. Of course this is not a fool proof way.
> 

There are other problems with several machines accessing an rpmdb
simultaneously, not the least of which is that Berkeley DB does not
support locking across NFS. I believe the fcntl scheme might "work"
across NFS, haven't looked seriously at all. There's also the Berkeley DB RPC
that could be used for several machines accessing an rpmdb. I believe that
most of the pieces are there, but, again, I haven't looked seriously at
using, only at configuring.

> I used sleep() to do the sleeping. This works on Solaris 2.6 and newer, 
> FreeBSD 4.3 and Linux. I do not have other OS' availible for testing.
> 
> Is this of any interest for rpm? Does it stand a chance to be included in 
> future releases? Should I file a bugreport with status "enhancement" and 
> attach patches there instead? http://www.rpm.org does not give too much 
> information about things, unfortunately.

Bug reports and enhancement requests in bugzilla
	http://bugzilla.redhat.com
please, as I sometimes abuse tha delete key when reading mail.

You might also look at patching against rpm-4.0.3 from the rpm-4_0
branch in CVS
	cvs -d :pserver:anonymous@cvs.rpm.org:/cvs/devel login
	(no password, just carriage return)
	cvs -d :pserver:anonymous@cvs.rpm.org:/cvs/devel get rpm
	cd rpm
	cvs up -r rpm-4_0
as there's quite a few changes in rpm-4.0.3.

73 de Jeff

-- 
Jeff Johnson	ARS N3NPQ
jbj@jbj.org	(jbj@redhat.com)
Chapel Hill, NC