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 [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.") 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: https://lists.fedoraproject.org/pipermail/devel/2010-April/135037.html """I started the "yum -y update", and didn't hang around to watch everything.""" ...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 > themselves. 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 the computer. > 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? 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 fixed. > 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. _______________________________________________ Yum-devel mailing list Yum-devel@lists.baseurl.org http://lists.baseurl.org/mailman/listinfo/yum-devel
