1 |
On Wed, 7 Sep 2011 23:23:45 -0400 |
2 |
Canek Peláez Valdés <caneko@×××××.com> wrote: |
3 |
|
4 |
> > I wound up being able to recover by doing a full reinstall of all |
5 |
> > packages on the live system after mounting /usr into a |
6 |
> > freshly-mkfs'd new lvm volume. If I'd taken the system offline, it |
7 |
> > would have been much more difficult. |
8 |
> |
9 |
> You can always remount / in another LVM module. Really, what's so |
10 |
> especial about /usr? |
11 |
|
12 |
Don't get me started. Oh, wait, you just did. |
13 |
|
14 |
Right, here goes: |
15 |
|
16 |
An initramfs is optional becuase i can disable it in the kernel. I |
17 |
would like to keep that optional. |
18 |
|
19 |
FHS says I can have /usr on a separate partition and I would like to |
20 |
keep that because it is a good idea. |
21 |
|
22 |
FHS says I can mount /usr read-only if I choose, which is also a good |
23 |
idea. On a shared jumphost with 570 concurrent users it's actually a |
24 |
VERY GOOD ODEA and I'd rather not lose that facility thankyouverymuch. |
25 |
|
26 |
I do not need, want nor can I find a valid reason to *require* an |
27 |
initramfs. Systems boot just fine without them. |
28 |
|
29 |
FHS says I can have the minimal software and tools to effect a system |
30 |
repair on / and put then entirety of user-space on /usr. Everything |
31 |
involved in this thread runs early in the boot process and I fail to |
32 |
find a single convincing reason why /usr is involved at all. Anything |
33 |
required at this point can simply be put into /bin, /sbin and /lib{,64} |
34 |
which one will note is exactly how we have been doing it all along. |
35 |
|
36 |
This whole mess has every indication of a singular maintainer who |
37 |
cannot be bothered taking other people's needs into account and |
38 |
foisting off his own personal preferences onto an entire ecosystem. |
39 |
|
40 |
I think such people should take note of how Torvalds works and emulate |
41 |
him as opposed to emulating say Drepper as a role-model for good |
42 |
project mantainership practice. |
43 |
|
44 |
-- |
45 |
Alan McKinnnon |
46 |
alan.mckinnon@×××××.com |