On Tue, Dec 18, 2012 at 9:33 AM, Alan McKinnon <[email protected]> wrote: > On Tue, 18 Dec 2012 09:08:53 -0500 > Michael Mol <[email protected]> wrote: > > > This sentence summarizes my understanding of your post nicely: > >> Now, why is /usr special? It's because it contains executable code the >> system might require while launching. > > Now there are only two approaches that could solve that problem: > > 1. Avoid it entirely > 2. Deal with it using any of a variety of bootstrap techniques > > #1 is handled by policy, whereby any code the system might require > while launching is not in /usr.
This is the solution I favor. Systemic structure which allows dependency leakage is indicative (to me) of lack of foresight and proper component role limitation, and ought to be fought. > > #2 already has a solution, it's called an init*. Other solutions exist > but none are as elegant as a throwaway temporary filesystem in RAM. I find virtually nothing elegant about a temporary filesystem in RAM. It duplicates code that already exists on the system, and it represents and additional maintenance step in system upgrades. It seems almost a given that if someone is keeping multiple kernel images on a system, they're not updating the initr* for each when binaries that would be found in each are upgraded or rebuilt. In Debian, Ubuntu and others, this is handled by a post-install hook where the initr* image is rebuilt. To me, this honestly feels like a hack. In something like Gentoo, I'd rather see package placement driven by whether or not it will be needed to get all mount points mounted. If that means i18n databases under something like /boot/data, that seems reasonable. To me, the only cases where initr* feels like the right solution are things like netboot or booting from read-only media. > > I should be clear that I do not necessarily support Lennart's > solutions, but I do support his perception of the problem (at least > partially). We cannot support situations where *launch* code is > haphazardly scattered in location X and this must always work for all > values of X. We already have a remarkably parallel situation in /boot - > in order to boot at all, the code running at that point in time needs > to be able to find stuff, and it finds it (by policy) in what we will > later call /boot. I see this /usr debate as the same thing on a larger > scale. -- :wq
