| 1 |
>>>>> On Thu, 1 Aug 2013, Rich Freeman wrote: |
| 2 |
|
| 3 |
> On Thu, Aug 1, 2013 at 4:04 PM, Alexis Ballier <aballier@g.o> |
| 4 |
> wrote: |
| 5 |
>> I have no opinion whether separate usr should be supported or not: |
| 6 |
>> I have not been using this layout since years. However, I strongly |
| 7 |
>> prefer some kind of consistency: The traditional layout with a |
| 8 |
>> minimal / to boot or the usr move both have their advantages; if we |
| 9 |
>> go for something in between we get none of them. |
| 10 |
|
| 11 |
> I tend to loosely agree here. |
| 12 |
|
| 13 |
> My inclination right now is to support this proposal if either of |
| 14 |
> the following is true: |
| 15 |
> 1. Somebody explains that right now the absence of a decision is |
| 16 |
> causing them actual problems (extra work, limitations, whatever). |
| 17 |
> 2. This becomes necessary to enable some larger long-term goal, |
| 18 |
> which has received council approval. |
| 19 |
|
| 20 |
> #2 was basically covered by Alexis already. |
| 21 |
|
| 22 |
> Regarding #1, I informally emailed the base-system maintainers a |
| 23 |
> week ago about whether there was any need to revisit last year's |
| 24 |
> decision. I didn't really get a sense that anybody really needed the |
| 25 |
> council to step in now. I recognize that William is also a |
| 26 |
> base-system maintainer so if he wants to state that he is subject to |
| 27 |
> some kind of extra work or such supporting separate /usr without an |
| 28 |
> early boot workaround I'll certainly be sympathetic. |
| 29 |
|
| 30 |
> I do favor the dropping of support for separate /usr without an |
| 31 |
> early boot workaround. I just don't think the council should |
| 32 |
> actually step in until somebody needs us to, or as part of some |
| 33 |
> larger plan. If the base-system maintainers have things under |
| 34 |
> control, better to let them handle it. |
| 35 |
|
| 36 |
I mostly agree with aballier and rich0. |
| 37 |
|
| 38 |
It so happened that I had chaired the 2012-04 council meeting and it |
| 39 |
seems that I failed to make sure that the vote was on a well-defined |
| 40 |
question. |
| 41 |
|
| 42 |
Trying to interpret or clarify that 2012-04 vote won't help much: |
| 43 |
That a separate /usr _with_ an initramfs is supported is self-evident, |
| 44 |
so it would have been moot to vote on this. OTOH, a separate /usr |
| 45 |
being supported _without_ an initramfs raises the question what |
| 46 |
"supported" means. Obviously there are situations where such a |
| 47 |
configuration doesn't currently work, and it is not even clear if |
| 48 |
making it work would be feasible. For example, if a user chooses to |
| 49 |
emerge sys-apps/shadow with cracklib and pam USE flags enabled, then |
| 50 |
he cannot expect it to be fully functional without /usr being mounted. |
| 51 |
So there _is_ some amount of inconsistency already, and maybe it's not |
| 52 |
even fixable, given the many possible configurations with different |
| 53 |
USE flags. (For a binary distro, it may be easier.) However, for basic |
| 54 |
configurations, like the one used for stage3, the root file system |
| 55 |
still seems to be self-supporting. |
| 56 |
|
| 57 |
I think one thing to consider is where we want to go in the long term. |
| 58 |
The FHS [1] specifies binaries that must be in /bin and /sbin, mainly |
| 59 |
sys-apps/coreutils, sys-apps/util-linux, sys-apps/shadow, and a |
| 60 |
handful of others (that are related to networking, archiving, system |
| 61 |
boot and shutdown). Shared libraries needed by these binaries must be |
| 62 |
in /lib*. |
| 63 |
|
| 64 |
Shall we stick to this FHS requirement, as far as it is technically |
| 65 |
feasible, or shall we do the /usr merge which also has benefits? Or |
| 66 |
some middle ground between these two solutions? (But I'm with aballier |
| 67 |
here, that would lead to further inconsistencies and we won't get the |
| 68 |
advantages of either solution.) Are we even ready to decide on this |
| 69 |
question yet? |
| 70 |
|
| 71 |
What shall we do in the short term? For the upcoming council meeting, |
| 72 |
the following questions come to mind: |
| 73 |
- Do we need any new decisions at all? Or are we confident that |
| 74 |
maintainers (mainly base-system) will do the right thing? |
| 75 |
- Should binaries stay in /bin or /sbin if the FHS says so, or if |
| 76 |
they're otherwise needed for booting? (For the time being, until we |
| 77 |
make up our mind about the /usr merge?) |
| 78 |
- Are shared libraries needed by binaries in /bin or /sbin to be |
| 79 |
installed in /lib*? |
| 80 |
- Do we discourage moving further programs from /usr to /, in order |
| 81 |
to keep the root filesystem at a small size? Even if this causes |
| 82 |
inconsistencies in some configurations? |
| 83 |
|
| 84 |
Ulrich |
| 85 |
|
| 86 |
[1] http://www.linuxbase.org/betaspecs/fhs/fhs/ch03.html |
Archives