my take on the protected packages problem

Panu Matilainen pmatilai at laiskiainen.org
Wed Jan 8 16:33:11 UTC 2014


On 01/08/2014 12:26 PM, Ales Kozumplik wrote:
> Hello,
>
> I'll miss the #yum meeting today but in case this topic comes up, I'd
> like to state where I stand:
>
> First of all, I feel like I might be starting to get biased here, but no
> less so then the whole fedora-devel thread. What I'd like to suggest is
> wait for this to calm down and then wait for people coming back still
> (random users, not the fedora devel crowd) complaining we broke their
> use case. And then trying to see how to consistently provide solutions
> for that. Re-adding protected packages is one option, perhaps with
> better specified semantics then there is in yum.conf [1] (I dislike the
> "Also if this configuration is set to anything, then yum will protect
> the package corresponding to the running version of the kernel.")
>
> But we should remember that there will have to be a default setting of
> that config value---is kernel going to be in it or not? We shouldn't
> forget that there are people who welcomed the change. And also: if one
> does 'dnf erase kernel', there is still the transaction confirmation
> prompt asking him if he really wants to remove these 5 kernels. Perhaps
> all we need is highlighting the running kernel in the overview somehow.
>
> Another thing is the '--all' switch that would force over the protected
> packages. I kind of liked it first. But we already have the '-y' switch
> that says 'yeah, really, whatever'. We know there is a large semantic
> difference between the two, but will the users who spent 3 minutes *at
> best* reading the man page know? Or will they be confused? I generally
> try to reduce the number of config options and CLI switches, not add them.
>
> But as I said, I'd prefer this topic to cool off for a while, see how
> things evolve.

My 5c is that the protected packages thing is a slippery slope that 
easily leads to a false sense of security as there are TONNES of 
"critical" packages which are not covered by defaults or the packages 
themselves.

By default, something like 'yum remove iputils' will merrily proceed 
without triggering package protection alerts and good luck trying to 
reinstall packages when all your network tools are gone. Well, hopefully 
you have a bootable and network-enabled rescue-image at hand in case you 
dont happen to have up-to-date copies of the packages around. Recovering 
from erasing a running kernel underneath you is likely easier, at least 
if you realize the mistake before rebooting (after reboot you'll also 
need the rescue-image)

Also the notion of running tends to be at odds with package management 
in various ways. There's zero protection against removing packages that 
have instance(s) running. Lot of software will continue to function to 
some extent, but eg firefox will start acting rather strange sooner or 
later, and I wouldn't be surprised if eg libreoffice was the same. What 
if removing a package causes a running application to crash and lose 
your full days work, do the users get to blame the package manager from 
not protecting you from yourself? Should yum/dnf/whatever refuse to 
remove packages which are in use? Me thinks not, but that's the 
direction the "but foo didn't protect me!" thinking leads...

This is of course all solved by extending offline updates to apply to 
software install and erase as well ;)

	- Panu -


More information about the Yum-devel mailing list