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