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:
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.
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.
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.