On 03/02/2013 16:54, Neil Bothwick wrote: > This isn't about a lack of convenience, this upgrade WILL break a > computer that was working beforehand, and not tell the user about it > until after the damage is done. I'm not saying it is easy to find a > solution that helps avoid breaking while not inconveniencing others, but > that is no reason to not try.
OK. So here's what we have. gentoo-dev thrashed this same conversation to death with equally ambiguous results. There too a lot of people were saying "But we shouldn't break user's machines!" And there was vast consensus about that. The next post invariably said something like "We must do <insert current poster's bright idea here>!" And the reply to that was almost always "OK hotshot, you covered situation A (coincidentally your situation)> Now, what about valid situations `seq B J` - *all of which are supported*. Please provide a plan for those." And the response to that usually started with "Um..." and didn't actually contain an answer. So I say to you "Neil, what is your solution for all the myriad configurations possible that DO NOT resemble your own? We know what your preferred solution is, as you stated it clearly, but I am interested in all those other users not covered by that. Please provide a well thought out solution that works for them as well as yours would work for you." I'll bet good money you come to the same conclusion I did (based on the conclusions on gentoo-dev):: - trying to infer something from the current running kernel, or /usr/src/linux/.config or some magic name in /boot/ is pointless and leads to so many false positives it isn't worth the effort in the general case. - a console message and an elog generated in one of the *pre hooks is about as good as it gets ... - ... backed up by a news item before the time so forewarned users are forearmed users - the devs did in fact cock up gloriously by omitting all prior notification and learned a bitter lesson - whatever the devs do, this version of udev is going to fuck things up horribly for a lot of people - despite what Lennart and co will whinge after the fact, the real problem lies with udev and it's complete lack of any fallback should DEVTMPFS not be available. This last one is to my mind crucial. Who cares what kind of filesystem /dev is mounted as? It's a filesystem, it's not uber-magic. it's a place where udev can stick it's nodes. If it doesn't have a tmpfs, well then it can wait till / is mounted and write it's stuff there. udev already has a guarantee that /dev will exist as soon as / is mounted, even if /dev is part of / What's this mandatory tmpfs all about anyway? Why is a userspace daemon dictating mandatory kernel behaviour, especially regarding something that, by design (mount points), is supposed to be transparent to everything under the sun moon earth and stars? -- alan.mckin...@gmail.com
