Bug 839514
| Summary: | RFE: yum protect packages to allow versions | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Wolfgang Denk <wd> |
| Component: | yum | Assignee: | Fedora Packaging Toolset Team <packaging-team> |
| Status: | CLOSED WONTFIX | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | high | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 18 | CC: | ffesti, frankly3d, james.antill, jzeleny, maxamillion, packaging-team, tim.lauridsen |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2014-02-05 12:02:07 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
|
Description
Wolfgang Denk
2012-07-12 07:46:02 UTC
Hi, This is core Yum functionality, no plugin is needed. The /etc/yum/protected.d/*.conf files list package names only. Version/arch/release of the package to be removed is not used. (In reply to comment #1) > > This is core Yum functionality, no plugin is needed. The Then the documentation is wrong, see the "Software Management Guide" at http://docs.fedoraproject.org/en-US/Fedora/14/html-single/Software_Management_Guide/index.html#id879927 > /etc/yum/protected.d/*.conf files list package names only. > Version/arch/release of the package to be removed is not used. This does not work either: # cat /etc/yum/protected.d/kernel.conf kernel kernel-devel kernel-modules-extra kmod-nvidia # yum remove kernel-3.3.4-5.fc17.x86_64 Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto Resolving Dependencies --> Running transaction check ---> Package kernel.x86_64 0:3.3.4-5.fc17 will be erased --> Processing Dependency: kernel-uname-r = 3.3.4-5.fc17.x86_64 for package: 1:kmod-nvidia-3.3.4-5.fc17.x86_64-295.59-1.fc17.x86_64 --> Processing Dependency: kernel-uname-r = 3.3.4-5.fc17.x86_64 for package: kernel-modules-extra-3.3.4-5.fc17.x86_64 --> Running transaction check ---> Package kernel-modules-extra.x86_64 0:3.3.4-5.fc17 will be erased ---> Package kmod-nvidia-3.3.4-5.fc17.x86_64.x86_64 1:295.59-1.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================== Package Arch Version Repository Size ====================================================================================================== Removing: kernel x86_64 3.3.4-5.fc17 @/kernel-3.3.4-5.fc17.x86_64 113 M Removing for dependencies: kernel-modules-extra x86_64 3.3.4-5.fc17 @/kernel-modules-extra-3.3.4-5.fc17.x86_64 6.9 M kmod-nvidia-3.3.4-5.fc17.x86_64 x86_64 1:295.59-1.fc17 installed 16 M Transaction Summary ====================================================================================================== Remove 1 Package (+2 Dependent packages) Installed size: 136 M Is this ok [y/N]: So this would happily remove the packages listed in the protected list. > Then the documentation is wrong, see the "Software Management Guide" "This feature was recently added to yum from a plugin called yum-plugin-protect-packages" - that seems to be correct, right? > This does not work either Hmm, interesting. Didn't you set protected_packages to something in yum.conf explicitly? That would have overriden the default "glob:/etc/yum/protected.d/*.conf". (In reply to comment #3) > > Then the documentation is wrong, see the "Software Management Guide" > > "This feature was recently added to yum from a plugin called > yum-plugin-protect-packages" - that seems to be correct, right? Hm... define "recently". Please note that this specific doucment appears to be from Fedora 14 times... > > This does not work either > > Hmm, interesting. Didn't you set protected_packages to something in > yum.conf explicitly? That would have overriden the default > "glob:/etc/yum/protected.d/*.conf". No, I have no modifications to yum.conf at all, and none anywhere else. I tried explicitly adding the "glob:" entry to yum.conf, but it did not change behaviour in any visible way. BTW - using strace I can see that yum actually accesses the information in /etc/yum/protected.d/* , but it seems to ignore it: 12291 open("/etc/yum/protected.d/kernel.conf", O_RDONLY) = 5 12291 read(5, "kernel\nkernel-devel\nkernel-modul"..., 8192) = 53 12291 read(5, "", 4096) = 0 12291 read(5, "", 8192) = 0 [Hm... I have no idea why it does this second read(), this is bogus. Seems this code is not exactly standard conforming.] Best regards, Wolfgang Denk The 2nd read() is ok (0 means EOF), and the 3rd one is an unrelated Python file iterator bug.
I can't reproduce the behavior you report (always get the "..which is protected" message). Maybe there's something else wrong in your setup.. Could you run yum under pydb, and place breakpoints (or put the asserts below) in /usr/lib/python2.7/site-packages/yum/__init__.py
@@ -1192,9 +1192,11 @@ class YumBase(depsolve.Depsolve):
# But we don't allow you to turn it off!:)
protect_states = [TS_OBSOLETED, TS_ERASE]
txmbrs = []
+ assert 'kernel' in self.conf.protected_packages, self.conf.protected_packages
if rescode == 2 and self.conf.protected_packages:
protected = set(self.conf.protected_packages)
txmbrs = self.tsInfo.getMembersWithState(None, protect_states)
+ assert len(txmbrs) > 1
bad_togo = {}
for txmbr in txmbrs:
if kern_pkgtup is not None and txmbr.pkgtup == kern_pkgtup:
(In reply to comment #2) > (In reply to comment #1) > > > > This is core Yum functionality, no plugin is needed. The > > Then the documentation is wrong, see the "Software Management Guide" > at > http://docs.fedoraproject.org/en-US/Fedora/14/html-single/ > Software_Management_Guide/index.html#id879927 > > > /etc/yum/protected.d/*.conf files list package names only. > > Version/arch/release of the package to be removed is not used. > > This does not work either: > > # cat /etc/yum/protected.d/kernel.conf > kernel > kernel-devel > kernel-modules-extra > kmod-nvidia > > # yum remove kernel-3.3.4-5.fc17.x86_64 Protected packages doesn't do what you think it does. It doesn't stop yum from ever touching a package with that name, it just stops it from removing/obsoleting it ... and in the case of an installonly package (like the kernel) it would stop it from removing the last version. Also, in the case of "kernel" we have a unique set of requirements because you shouldn't be able to remove a running kernel ... so that is hard coded into yum. You might be able to fake what you seem to want (never remove a specific version of the kernel) using versionlock ... but I can turn this into an RFE as well (although I'm not sure it's a good idea, as to do it well would require a lot more work). (In reply to comment #5) > The 2nd read() is ok (0 means EOF), and the 3rd one is an unrelated Python > file iterator bug. > > I can't reproduce the behavior you report (always get the "..which is > protected" message). Maybe there's something else wrong in your setup.. > Could you run yum under pydb, and place breakpoints (or put the asserts > below) in /usr/lib/python2.7/site-packages/yum/__init__.py Sure: # diff -u /usr/lib/python2.7/site-packages/yum/__init__.py{.ORIG,} --- /usr/lib/python2.7/site-packages/yum/__init__.py.ORIG 2012-06-25 10:14:56.000000000 +0200 +++ /usr/lib/python2.7/site-packages/yum/__init__.py 2012-07-12 23:09:03.097958225 +0200 @@ -1195,9 +1195,11 @@ # But we don't allow you to turn it off!:) protect_states = [TS_OBSOLETED, TS_ERASE] txmbrs = [] + assert 'kernel' in self.conf.protected_packages, self.conf.protected_packages if rescode == 2 and self.conf.protected_packages: protected = set(self.conf.protected_packages) txmbrs = self.tsInfo.getMembersWithState(None, protect_states) + assert len(txmbrs) > 1 bad_togo = {} for txmbr in txmbrs: if kern_pkgtup is not None and txmbr.pkgtup == kern_pkgtup: # uname -a Linux gemini.denx.de 3.3.4-5.fc17.x86_64 #1 SMP Mon May 7 17:29:34 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/yum/protected.d/kernel.conf kernel kernel-devel kernel-modules-extra kmod-nvidia # yum remove kernel-3.4.0-1.fc17.x86_64 Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto Resolving Dependencies --> Running transaction check ---> Package kernel.x86_64 0:3.4.0-1.fc17 will be erased --> Processing Dependency: kernel-uname-r = 3.4.0-1.fc17.x86_64 for package: 1:kmod-nvidia-3.4.0-1.fc17.x86_64-295.59-1.fc17.x86_64 --> Running transaction check ---> Package kmod-nvidia-3.4.0-1.fc17.x86_64.x86_64 1:295.59-1.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================== Package Arch Version Repository Size ====================================================================================================== Removing: kernel x86_64 3.4.0-1.fc17 @updates 114 M Removing for dependencies: kmod-nvidia-3.4.0-1.fc17.x86_64 x86_64 1:295.59-1.fc17 @rpmfusion-nonfree-updates 16 M Transaction Summary ====================================================================================================== Remove 1 Package (+1 Dependent package) Installed size: 130 M Is this ok [y/N]: I don't see any new output from the asserts ? (In reply to comment #6) > > Protected packages doesn't do what you think it does. It doesn't stop yum > from ever touching a package with that name, it just stops it from > removing/obsoleting it ... and in the case of an installonly package (like > the kernel) it would stop it from removing the last version. Ah! This would explain the behaviour I see. It would be nice to have this explanation in the yum.conf man page, though. > > You might be able to fake what you seem to want (never remove a specific > version of the kernel) using versionlock ... but I can turn this into an RFE > as well (although I'm not sure it's a good idea, as to do it well would > require a lot more work). Hm... how would I use versionlock? It appears this is not dowin what I expect either: # yum versionlock kernel-3.4.0-1.fc17.x86_64 Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto, versionlock Adding versionlock on: 0:kernel-3.4.0-1.fc17 versionlock added: 1 # yum remove kernel-3.4.0-1.fc17.x86_64 Loaded plugins: auto-update-debuginfo, fastestmirror, langpacks, presto, versionlock Resolving Dependencies --> Running transaction check ---> Package kernel.x86_64 0:3.4.0-1.fc17 will be erased --> Processing Dependency: kernel-uname-r = 3.4.0-1.fc17.x86_64 for package: 1:kmod-nvidia-3.4.0-1.fc17.x86_64-295.59-1.fc17.x86_64 --> Running transaction check ---> Package kmod-nvidia-3.4.0-1.fc17.x86_64.x86_64 1:295.59-1.fc17 will be erased --> Finished Dependency Resolution Dependencies Resolved ====================================================================================================== Package Arch Version Repository Size ====================================================================================================== Removing: kernel x86_64 3.4.0-1.fc17 @updates 114 M Removing for dependencies: kmod-nvidia-3.4.0-1.fc17.x86_64 x86_64 1:295.59-1.fc17 @rpmfusion-nonfree-updates 16 M Transaction Summary ====================================================================================================== Remove 1 Package (+1 Dependent package) Installed size: 130 M Is this ok [y/N]: n Exiting on user Command So again this would not prevent removal of the selected kernel image(s). Yeh, versionlock just stops yum seeing "upgrades" ... so the version you have won't be automatically removed via. an upgrade. If you also remove all the old versions of the kernel, then the only one installed will be the one you want ... and yum won't see any other ones, and yum will then not allow you to remove that version (because it's the only one). (In reply to comment #9) > Yeh, versionlock just stops yum seeing "upgrades" ... so the version you > have won't be automatically removed via. an upgrade. > If you also remove all the old versions of the kernel, then the only one > installed will be the one you want ... and yum won't see any other ones, and > yum will then not allow you to remove that version (because it's the only > one). But that's not what I want to do. I do want to be able to install updates, and the update process may remove all other, old versions of the kernel. I just want to make sure that one specific (the last known to be working) kernel version does not get auto-removed. Yum cannot do this? This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. This would be very handy for testing branched\rawhide kernels. But, if the work is warranted. With all the dnf talk This may be what we're all looking for: http://lists.baseurl.org/pipermail/yum/2013-October/024030.html This message is a reminder that Fedora 18 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 18. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '18'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 18's end of life. Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 18 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 18's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. Fedora 18 changed to end-of-life (EOL) status on 2014-01-14. Fedora 18 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed. |