Red Hat Bugzilla – Bug 57301
Feature request: locking packages so they can't be updated without explicitly being unlocked
Last modified: 2008-05-01 11:38:01 EDT
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):
Steps to Reproduce:
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.
You can already achieve a certain type of locking by
building and installing a package with
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.
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
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.
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.