Gentoo Archives: gentoo-user

From: pk <peterk2@××××××××.se>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] systemd installation location
Date: Tue, 01 Oct 2013 20:00:03
Message-Id: 524B29A1.2020102@coolmail.se
In Reply to: Re: [gentoo-user] systemd installation location by Alan McKinnon
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