| 1 |
On Sun, Aug 18, 2013 at 09:48:09PM -0500, William Hubbs wrote: |
| 2 |
> > I just don't see any reason for waiting, at least not right now. If |
| 3 |
> > the argument is that we should give users some period of time to |
| 4 |
> > prepare, then we should be sending out some kind of specific news item |
| 5 |
> > telling them what preparations to make and THEN waiting. |
| 6 |
> |
| 7 |
> The vote is to make sure all of the necessary documentation is in place, |
| 8 |
> so this isn't really part of it. But, yes, once this vote passes, |
| 9 |
> communication to users as the changes happen will be important. |
| 10 |
|
| 11 |
Documentation can always be improved, but I do feel it is up to the task |
| 12 |
already. We document how to create an initramfs using genkernel (which is |
| 13 |
dead easy) and mention several times that a separate /usr (or root on LVM) |
| 14 |
requires an initramfs. |
| 15 |
|
| 16 |
All our examples use the initramfs as well. |
| 17 |
|
| 18 |
> > Finally, I could see the /usr merge as a POSSIBLE reason to move |
| 19 |
> > things sooner. If somebody wants to propose some plan to make that |
| 20 |
> > happen they should do so, and we can debate it on this list and so on. |
| 21 |
> > However, I don't see any value in moving a bunch of stuff around |
| 22 |
> > purely for the sake of a /usr merge when there isn't any plan to |
| 23 |
> > finish the work. If anybody is thinking about that being the driver |
| 24 |
> > they need to have a plan that actually gets us to the end goal, and of |
| 25 |
> > course we need to agree that this is even a goal we want to have. |
| 26 |
> |
| 27 |
> The /usr merge is a totally separate issue that I really don't want to |
| 28 |
> bring into this discussion. There are people who are fine with us |
| 29 |
> cleaning up the separate /usr issue, but opposed to the /usr merge, so |
| 30 |
> that needs to be a separate item imo. |
| 31 |
|
| 32 |
Yes please; merging / <-> /usr has impact beyond just documentation and |
| 33 |
initramfs. For SELinux for instance, that means our policies will need to be |
| 34 |
adjusted so all /bin/* contexts also get assigned to /usr/bin (and /sbin to |
| 35 |
/usr/sbin) and symlinks are "accepted" where they are currently not. |
| 36 |
|
| 37 |
I think for such a merger, we'll need to know what will be the goal, and set |
| 38 |
steps in that direction that make it so a transition is not full-park, |
| 39 |
big-bang, but rather gradually with little to no end user involvement |
| 40 |
(step-wise). |
| 41 |
|
| 42 |
Wkr, |
| 43 |
Sven Vermeulen |
Archives