Bug 57301 - Feature request: locking packages so they can't be updated without explicitly being unlocked
Feature request: locking packages so they can't be updated without explicitly...
Status: CLOSED DEFERRED
Product: Red Hat Linux
Classification: Retired
Component: rpm (Show other bugs)
7.2
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jeff Johnson
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-12-09 05:03 EST by Dag Wieers
Modified: 2008-05-01 11:38 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-09 19:16:13 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 Dag Wieers 2001-12-09 05:03:12 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.6) Gecko/20011120

Description of problem:
A way to lock a package so rpm won't upgrade it automatically (even won't
force it) unless it is explicitely unlocked. (Maybe locking is not possible
from within the RPM-package itself to avoid 'sticking' packages that you
cannot uninstall or something). See it as a flag so you can tell other
administrators that this package has some 'importance' attached to it. Like
you could lock the
kernel-package on a certain system to draw the attention that it is a
custom package, or you can lock production-application to avoid they get
updated by your new colleague administrator.


Version-Release number of selected component (if applicable):


How reproducible:
Always

Steps to Reproduce:
1.-
2.
3.
	

Expected Results:  $ rpm -U kernel-2.4.9-13.i386.rpm
Updating kernel-package failed because an existing package was locked.
Type 'rpm -l -u kernel' to unlock the package.

Additional info:
Comment 1 Jeff Johnson 2001-12-09 12:21:28 EST
You can already achieve a certain type of locking by
building and installing a package with
	Requires: foo
I.e. foo will not be removed without breaking dependencies.

I don't think that mandatory locking ala chattr wrto chmod
is necessary or should be attempted in rpm. Save a copy of
the original package somewhere, reinstall if/when
needed instead of trying to "lock" the contents onto
the file system. IMHO that's a saner and more flexible
approach, as there's far too many ways around whatever
locking might be attempted by rpm.
Comment 2 Dag Wieers 2001-12-09 19:16:07 EST
Allow me to reopen it though.

rpm is a system administration tool and being able to lock a package would
greatly facilitate a sysadmins job.

There's no simple way of doing this another way (the same arguments as the
wrapper script, if it's not done in rpm it cannot be done safely). Debian has a
similar feature, called "Hold" and it allows to lock packages so they won't be
upgraded by mistake.

Saving and reinstalling a package is not a solution. It presumes that you know
immediately after the "upgrade-by-mistake" that you did something wrong and you
have to restore it. I'm talking about production-systems where you're using a
Red Hat apache-package with a specific version because you know a
vendor-application (not necessarily packaged) needs that specific Apache
package.

Or better yet (this is another real-life example) some installations we have
replaces existing binaries likes suexec (Apache developers advice to change the
suexec-program for specific needs) from the package. In this case we don't want
a fellow admin to upgrade the system (with Apache) by accident and overwrite the
suexec-binary. And not because we don't have a copy, but because it may go
unnoticed until the damage has been done (a customer finds out something hasn't
been working for days).

I'm talking here big company (I work for IBM) with hundreds of machines and a
big team of administrators (not all that experienced in RH yet). If we can
prevent mistakes to be made, and Red Hat allows us to do just that, this would
be a big win.

Again, if you could discuss this with other system administrators and/or
developers, it would be greatly appreciated. Thanks.
Comment 3 Jeff Johnson 2001-12-10 10:12:49 EST
The functionality you desire is already in up2date, which has both
	Never upgrade this package
	Never change this file
policies that can be configured. Yes, rpm from the CLI might benefit
from these policies as well. For now, however, the answer is up2date.

Note carefully that the word "locking" was not used in the previous
paragraph, nor is "locking" really desireable IMHO. What is needed
is better package install policies.

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