JBJ mentioned the need for consensus on binary level api compatibility --
I use autorpm heavily, and other shell scripting maintenance tools -- so
long as I can have CLI, change away.
One POSSIBLE RFE: Add a option:
to open the RPM database readonly -- and permit other competing
Readonly opens to succeed.
That is a dash-dash GNU style option -- no need for a short form ... only
folks reading the MAN pages should be using it
rpm only opens the database rdwrite during install/erase modes, all other opens
are rdonly. In fact, if --test is supplied, even install/erase modes are rdonly
Perhaps you want a resolution to the exclusive (on rdwrite) vs. shared (on
db locking issues. That's doable, but I'd like to get db1 out of the picture
attempting a solution. Is locking the underlying issue?
In TUI mode, there may be running a backgrounded rpm -Va off a
cron process, which with the new option could have instead
been started rpm -Va --readonly
During that time, another process may wish to either query [I think
this may already work, actually -- pretty sure as I think it through]
sequencing, or to have quick write access to the DB -- maybe an update
process -- or a quick install of a needed package -- and the later
process needing write access is blocked and errors.
(This is a change in scope -- adding the need to write in resp to the NEEDINFO)
OK, this is the locking issue, as an upgrade can not acquire an exclusive lock
a shared lock is held. Nor is it as simple as "Don't lock during -Va", as the
can/will be changed by the upgrade, causing all sorts of fun with random
Don't worry about NEEDINFO, that just pushes bug reports off my radar
any reply pops the state back to ASSIGNED.
rpm-4.0.3 has /etc/rpm/macros.cdb, uncomment
the one line configuration to try use a Berkeley
Concurrent Database (CDB) model for accessing
rpmdb with finer-grained per-cursor locks.
Reopen this bug when you find the one remaining
db3 problem, as access(2) for root used to choose
RW flags on db open will need a slight adjustment ...