my take on the protected packages problem
james at fedoraproject.org
Wed Jan 8 22:01:03 UTC 2014
On Wed, 2014-01-08 at 18:33 +0200, Panu Matilainen wrote:
> On 01/08/2014 12:26 PM, Ales Kozumplik wrote:
> > Hello,
> > First of all, I feel like I might be starting to get biased here, but no
> > less so then the whole fedora-devel thread.
So if there's one piece of advice you listen to here it's this:
Everyone will be biased about package management, and almost everyone
who speaks to you will be completely clueless.
In the last 5 or 6 years the vast majority of people who've spoken to
me have basically assumed that it's a trivial problem, and that you are
basically "maintaining" something that is one step up from a 3 line bash
script that calls curl and then tar -xvf.
So if you don't try to find out what people are actually complaining
about, and why, you aren't going to have a good time.
...I know the desire is to get angry and ignore everyone, but that's not
going to help. You are probably doomed anyway, so you need all the help
you can get.
> > 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.
This is just a bad idea for something as core as packaging, you can
think through what the problems are now ... you don't need to wait until
some random user hits a problem and hates you forever because something
blew up in their face they didn't expect.
> > Re-adding protected packages is one option, perhaps with
> > better specified semantics then there is in yum.conf  (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.")
Breaking backcompat. with one more config. UI thing isn't as free as
you think, but meh.
Note that the ini format doesn't lend itself to having a lot of nice
options. Personally I find it hard to believe that someone would want to
protect some packages, but not have the "protected" remove semantics for
the kernel so having N options for that is just confusing.
> > 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.
Ok, so maybe some history will help here:
What we "always" had in yum was that when yum obeyed
"installonly_limit" (traditionally an expedient hack just for the
kernel) it wouldn't remove the running kernel. This is kind of
"obvious", if you think about a server running for 666 days and
installonly_limit=3 meaning we'd remove the latest/running kernel in
only two "yum upgrades" that had a new kernel.
The fact the modulized kernel will fail in horrible ways if you remove
the version that is running doesn't need a user to hit it, it's still
true and if dnf doesn't at least do this much expect more happy threads
on f-d-l in the future.
We were good with just that for a _long_ time, but then this happened:
"""I started the "yum -y update", and didn't hang around to watch
...obviously adding more highlighting to the transaction output isn't
going to help here. So we added protected_packages.
But, meh., yum lasted many years before someone who I respected said
"yum just deleted my computer, and that's bad" ... and I could probably
have ignored it even then.
Having "yum remove kernel" not put the running kernel into the
transaction was a change a couple of months after that, and IIRC was
prompted by RHEL QA ... which also helps explain why I just reused the
protected_packages config. option.
It was one of those weird things where I was pretty sure I'd never
wanted/needed to do that before, as I'd know to paste all the running
versions in, but I could see that it was obviously wrong to just remove
the running kernel and this was a trivial fix for that.
FWIW a couple of times since then I've used the feature to cleanup
space in /boot, but again meh.
> 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
Two obvious things here:
1. Perfect is the enemy of good. Just because we can't automatically
know that if my-foo-pkg is removed your machine won't
boot/update/whatever _doesn't_ mean we can't be intelligent enough to
know that if the user removes the last version of glibc/rpm/yum that's
installed they better _really_ mean it.
It's not hard to solve 95%+ of the real world problems here, which
translates to countless people not thinking bad thoughts (or worse)
about you/dnf because their computer didn't get trashed.
2. The way the feature was designed is that any random package can put a
file in /etc/yum/protected.d with their package name in it. Thus. if
my-foo-pkg is a really important package to you then it's trivial to
change my-foo-pkg to have a file that protects itself, or use
puppet/etc. to do the same if you can't alter the package itself.
> 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.
This is also true, and instead of fixing it we just moved to "offline
updates" ... welcome to the new world where packaging is just a little
bit worse/worthless, forever.
For non-broken apps. something like "service condrestart" was used in
the "old world" and the kernel is kind of special from that point of
view in that it's the _hardest_ to restart without actually restarting
> 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?
I can guarantee they will, and I'd bet that a UI designer would
certainly argue that any package management GUI shouldn't be removing
running desktop apps. and that if it does it's a bug that should be
> 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...
If it could be easily (efficiently) implemented, and we didn't, I'm not
sure what we'd gain by not helping.
> This is of course all solved by extending offline updates to apply to
> software install and erase as well ;)
That's the new new world, we can welcome that soon enough I think.
More information about the Yum-devel