Greg KH posted on Fri, 14 Dec 2012 12:04:03 -0800 as excerpted: > n Fri, Dec 14, 2012 at 01:28:00PM -0600, William Hubbs wrote: >> On Fri, Dec 14, 2012 at 02:05:27PM -0500, Ian Stakenvicius wrote: >> > On 14/12/12 01:28 PM, Greg KH wrote:
>> > > udev was never the problem of having a separate /usr without an >> > > initrd. Have all of the other packages been properly fixed to >> > > resolve this issue correctly? >> > It should be noted that sys-fs/udev (the package) since .. 186 I >> > think? whichever version dropped support for the failed-rules queue >> > (and whichever package dropped the udev-postmount init script) does >> > not support booting with a separate /usr. This has more to do with >> > how the package installs than the upstream code itself, though; as >> > such (WilliamH please correct me if I'm wrong) the plan is still to >> > require an initramfs if using sys-fs/udev with a separate-/usr. >> >> Greg, can you write back to this message with specific examples of what >> would need to be customized so that separate /usr would work right >> without an initramfs? I have tried to explain multiple times that this >> is a mis-conception that udev caused it, but I am getting nowhere. > > It's not my job to do this, nor yours, or fix any of these issues. It's > up to the people who wish to keep a separate /usr partition without an > initramfs to do this work. There's a saying, extreme claims require extreme proof. I don't personally have a stake in this as by personal policy my root includes /usr, but... for (1) people who had a separate /usr, who then (2) had that break with a udev upgrade, and (3) saw the very high visibility claims that despite the evidence of their own eyes, udev was *NOT* what broke things... To these people, the claim that udev was NOT what broke (non initr*) boot of a separate /usr system, looks rather extreme. Yet the people who made that claim both: 1) Continue to make it, just as strenuously and high visibility as they did before, and 2) Continue to try to shift responsibility for proving evidence for that claim, despite the (a) "I was THERE!" evidence many have that a udev update is what broke things for THEM and (b) the high visibility yet evidently "extreme" (from the point of view of those who saw the breakage happen with a udev update) claims to the contrary. There's a discontinuity there. Either udev wasn't the problem and those claiming it was should be easily able to provide a list of (non-corner- case) examples where it was broken previously, or udev WAS the problem, as they "I was THERE!" evidence of many users suggest. Yet those making the (to those that were "there") extreme claim continue to avoid providing appropriate evidence to back it up, saying it's not their job to provide such evidence, despite the /apparent/ extremity of their claim. This sort of /apparent/ illogic and refusal to justify apparently arbitrary decisions only contributes to the unfortunate situation. Oh, well, both the making of sausage and the making of law is said not to be pretty, who ever expected the making and evolution of FLOSS platform software to be pretty. Surprisingly, despite the issues, we always seem to muddle thru, and the problems eventually resolve themselves to a reasonably stable situation of either a major dominance of one solution (see xorg/xfree86), or of competing multiple solutions (see emacs/vi or kde/gnome/xfce/...), over time. Regardless of any temporary angst, I suppose the same will ultimately apply here. From a third party perspective, however, some of that angst sure seems unnecessary. <shrug> -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
