Bug 30830 - RFE: Add an option: --readonly
RFE: Add an option: --readonly
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.0
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
David Lawrence
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-03-06 12:56 EST by R P Herrold
Modified: 2007-04-18 12:32 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-03-06 14:00:21 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description R P Herrold 2001-03-06 12:56:45 EST
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
Comment 1 Jeff Johnson 2001-03-06 13:11:39 EST
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?
Comment 2 R P Herrold 2001-03-06 13:55:25 EST
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 14:00:14 EST
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.
Comment 4 Jeff Johnson 2001-08-30 13:48:57 EDT
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.