Mike Gilbert wrote: > On 04/22/2012 05:28 AM, Steven J Long wrote: >> "To clarify, the question is whether or not we support a separate /usr >> _without_ mounting it early via an initramfs." >> >> I hope that settles that particular issue. >> > > Hmm... I see that in Zac's reply, thanks for that. > > Unfortunately, from what I can tell, that clarification was not actually > part of the proposed agenda [5], nor was it directly referenced. So the > subject of the vote still seems open to interpretation. > Chainsaw proposed the item. zmedico immediately clarified that it was about supporting separate /usr without an initramfs mounting it.
Chainsaw was asked to describe the issue. He was asked whether a "minimal universal" initramfs was a sufficient solution, and he explicity turned it down. All further discussion was about who would continue to maintain any patches that might be needed. Again, those could not have been needed, unless one were discussing split /usr without an initramfs, since udev with an initramfs already supports a separate /usr. Or do you disagree? To say that it was not referenced in the discussion seems disingenuous: it _was_ the topic of discussion. > Ultimately, the council's only "power" is to stop things from happening > under threat of expulsion from the project. I think it would be a > mistake for this particular council vote to be used as the sole > justification for preventing devs from committing changes that would > require an initramfs for separate /usr support. It simply does not seem > clear enough for that. > Woah, no-one's even talking about anything along those lines. The Council *does* decide on overall technical policy, and this procedure is used for eg resolution of PMS and EAPI issues. Obviously, like all collaborative processes, and indeed policing in general, it only works by consent. There's no issue of changes to udev, since those can be handled at initscript/ busybox-applet level for those who want to continue without an initramfs and split partitioning. There might be future problems with linkage, but I've already stated a couple of times, that the same issues arise for the newer use-case of an initramfs, and it would make sense to tackle those systematically for at least some tools like lvm and mdadm. Given the systematic ability, it's much easier for users to apply elsewhere, and has other uses (basically doing it right is LDEPEND or required-link deps which slot operators do *not* cover.) What's wrong with doing that, so we all cooperate and we all benefit, instead of arguing? Anyhow, wrt what the Council was actually discussing (remember that split /usr with an initramfs is a technical non-issue) as before, I'd like the Council just to clarify. Guess I'll have to raise it on the agenda so they have to discuss it again? Regards, Steve. -- #friendly-coders -- We're friendly, but we're not /that/ friendly ;-)
