1 |
On 2013-10-01 08:16, Alan McKinnon wrote: |
2 |
|
3 |
> There are many examples in /usr you could have used to illustrate your |
4 |
> point, such as many fuse modules. And yet you chose an imaginary space |
5 |
> invader game. |
6 |
> |
7 |
> Let's rather stick within the bounds of what is feasible, OK? |
8 |
|
9 |
What can I say, I like to exaggerate... :-) |
10 |
But it seems you got my point. Although I would not rule out "Space |
11 |
Invaders" as either imaginary (it came out in 1978) nor infeasible (at |
12 |
boot). |
13 |
|
14 |
> But it's not just you. You are not running LFS, you are running Gentoo. |
15 |
> It has ebuilds and ebuilds put the generated files somewhere, and that |
16 |
> destination is the same for every user of that ebuild. |
17 |
|
18 |
Which is why I said what I said further down in the mail you replied to... |
19 |
|
20 |
> Unix, by design and unlike a traditional mainframe OS, does not |
21 |
> distinguish between different types of files and does limit where you |
22 |
> can put files. This has two consequences - you can do virtually anything |
23 |
> you like with it as everything is a file, and filesystem files and |
24 |
> structure have been moved out to human space in the hands of the |
25 |
> sysadmin/packager/maintainer/user or whatever. Some sanity must prevail. |
26 |
|
27 |
Yes, sanity is what I'm after but it seems I'm in the minority... |
28 |
|
29 |
> The Linux boot process can conceivably run any arbitrary code it needs |
30 |
> to run to get userspace into a runnable state. This can easily be code |
31 |
> that we haven't conceived of yet and becuase it is Unix, it could reside |
32 |
> anywhere. Also because it's Unix and because sysadmins have learned over |
33 |
> the years we constrain ourselves to putting the code in the bin, sbin |
34 |
> and lib directories in / and in /usr. |
35 |
> |
36 |
> Clearly, there is a massive distinction between code there and in say |
37 |
> /opt or /var/lib, that is why you won't find boot-critical code there. |
38 |
> But there is no such clear distinction between / and /usr. What *you* |
39 |
> think is not boot critical may be criticial for someone else. |
40 |
|
41 |
I couldn't agree more. However, since some devs (and I don't mean anyone |
42 |
in particular) have started to expect /usr to always be available for |
43 |
"boot-critical" software then what is to say that the next one *will* |
44 |
require /opt and/or /var/lib at boot time? And where do we make a |
45 |
distinction between a boot-critical thing and a non-boot-critical thing. |
46 |
For all I know there may actually be someone out there seriously |
47 |
considering adding "Space Invaders" as a boot thing for, say sysops that |
48 |
want to reboot a really big server and want to play while booting... I'm |
49 |
only kidding of course and hope noone takes this seriously!? ;-) |
50 |
|
51 |
> And here's the kicker: |
52 |
> |
53 |
> You don't get to decide for the other guy. But the packager gets to |
54 |
> support him, and has to edit ebuilds to install all the necessary code |
55 |
> not in /usr but in /. And they have to do this over and over and over, |
56 |
> and while they are doing that they have to answer users like you who are |
57 |
> complinaing about unneccessary rebuilds just to change the desitnation |
58 |
> of a few files. |
59 |
> |
60 |
> This is a no-win-ever situation for devs and they have decided they are |
61 |
> not doing it anymore and have made a decision to not support separate |
62 |
> /usr without initramfs. that is their right as you do not pay them a salary. |
63 |
> |
64 |
> This is the correct decision for Gentoo to have made, as the problem is |
65 |
> open ended and is never completed, plus there is no clear distinction |
66 |
> between what is boot critical in the general case and what is not. if |
67 |
> you can't see or understand that, then we have nothing more to discuss. |
68 |
> |
69 |
> If you don't like what Gentoo has done then I recommend you take it like |
70 |
> a man and fork. Assume the maintenanceburden yourself. |
71 |
|
72 |
I've already come to that conclusion myself (as, again, I mentioned in |
73 |
my mail further down). |
74 |
|
75 |
Bye, so long and thanks for the f*sh! |
76 |
|
77 |
Best regards |
78 |
|
79 |
Peter K |