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: --readonly 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 IIRC. Perhaps you want a resolution to the exclusive (on rdwrite) vs. shared (on rdonly) db locking issues. That's doable, but I'd like to get db1 out of the picture before 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 while a shared lock is held. Nor is it as simple as "Don't lock during -Va", as the database can/will be changed by the upgrade, causing all sorts of fun with random segfaults. Don't worry about NEEDINFO, that just pushes bug reports off my radar temporarily, 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 ...