Bug 30830 - RFE: Add an option: --readonly
Summary: RFE: Add an option: --readonly
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: rpm
Version: 7.0
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Jeff Johnson
QA Contact: David Lawrence
Keywords: FutureFeature
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-06 17:56 UTC by R P Herrold
Modified: 2007-04-18 16:32 UTC (History)
0 users

Clone Of:
Last Closed: 2001-03-06 19:00:21 UTC

Attachments (Terms of Use)

Description R P Herrold 2001-03-06 17:56:45 UTC
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

Comment 1 Jeff Johnson 2001-03-06 18:11:39 UTC
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?

Comment 2 R P Herrold 2001-03-06 18:55:25 UTC
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)

Comment 3 Jeff Johnson 2001-03-06 19:00:14 UTC
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.

Comment 4 Jeff Johnson 2001-08-30 17:48:57 UTC
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 ...

Note You need to log in before you can comment on or make changes to this bug.