Bug 839514 - RFE: yum protect packages to allow versions
RFE: yum protect packages to allow versions
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: yum (Show other bugs)
18
All Linux
unspecified Severity high
: ---
: ---
Assigned To: Fedora Packaging Toolset Team
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-07-12 03:46 EDT by Wolfgang Denk
Modified: 2014-02-05 07:02 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-02-05 07:02:07 EST
Type: Bug
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 Wolfgang Denk 2012-07-12 03:46:02 EDT
Description of problem:

Adding lists of protected packages to /etc/yum/protected.d/*.conf does
not work.  Yum also does not list "protect-packages" in list of loaded
plugins.  I cannot find any such plugin anywhere either, i. e. there
is for example no such file as /usr/lib/yum-plugins/protect-*
"yum provides /usr/lib/yum-plugins/protect-*" returns "No Matches
found".

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

yum-3.4.3-28.fc17.noarch

How reproducible:

100%

Steps to Reproduce:
1. Install some packet you don't really need, say:
   yum install kernel-3.3.4-5
2. Try to protect this package:
   echo kernel-3.3.4-5 >/etc/yum/protected.d/kernel.conf
3. Try to remove the package:
   yum remove kernel-3.3.4-5
  
Actual results:

Package can be removed.

Expected results:

According to the yum.conf man page and
http://docs.fedoraproject.org/en-US/Fedora/14/html/Software_Management_Guide/ch04s08s07.html
the package removal should be prevented with some message like

Error: Trying to remove "...", which is protected

None of this happens.

Additional info:

The yum.conf man page reads a bit strange:


              protected_packages  This is a list of packages that yum
              should never completely remove. They are protected via.
              Obsoletes as well as user/plugin removals.

I cannot parse the "They are protected via. Obsoletes as well as
user/plugin removals." part.
Comment 1 Zdeněk Pavlas 2012-07-12 05:11:15 EDT
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.
Comment 2 Wolfgang Denk 2012-07-12 05:44:33 EDT
(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.
Comment 3 Zdeněk Pavlas 2012-07-12 06:04:20 EDT
> 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".
Comment 4 Wolfgang Denk 2012-07-12 07:03:28 EDT
(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
Comment 5 Zdeněk Pavlas 2012-07-12 07:44:52 EDT
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:
Comment 6 James Antill 2012-07-12 09:59:57 EDT
(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).
Comment 7 Wolfgang Denk 2012-07-12 17:16:46 EDT
(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 ?
Comment 8 Wolfgang Denk 2012-07-12 17:28:00 EDT
(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).
Comment 9 James Antill 2012-07-16 15:18:43 EDT
 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).
Comment 10 Wolfgang Denk 2012-07-16 16:17:03 EDT
(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?
Comment 11 Fedora End Of Life 2013-07-03 22:19:03 EDT
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.
Comment 12 Frank Murphy 2013-10-10 04:13:14 EDT
This would be very handy for testing branched\rawhide kernels.
But, if the work is warranted. With all the dnf talk
Comment 13 Frank Murphy 2013-10-14 11:49:38 EDT
This may be what we're all looking for:
http://lists.baseurl.org/pipermail/yum/2013-October/024030.html
Comment 14 Fedora End Of Life 2013-12-21 03:39:39 EST
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.
Comment 15 Fedora End Of Life 2014-02-05 07:02:12 EST
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.

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