From 3d55920e9bbd3bf9374fcf0b6801e991df8f55fd Mon Sep 17 00:00:00 2001 From: Didier Raboud Date: Fri, 22 Feb 2019 10:55:11 +0100 Subject: [PATCH] 914897: Clarify /usr sharing between hosts/containers --- 914897_merged_usr/ballot.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/914897_merged_usr/ballot.md b/914897_merged_usr/ballot.md index 6a2237f..bef8ead 100644 --- a/914897_merged_usr/ballot.md +++ b/914897_merged_usr/ballot.md @@ -6,7 +6,7 @@ The motivation to get Debian systems to converge towards such a scheme is vastly documented elsewhere ([FDO's TheCaseForTheUsrMerge][0], [wiki.d.o UsrMerge][1]) but can be summarized as the following points: * having separate `/` and `/usr` filesystems has been useful in the past for booting without initramfs onto a minimal root filesystem that carried just enough to mount the `/usr` filesystem later in the boot process. Given the evolution of physical hosts' capabilities, initramfs'es have been default in Debian (and elsewhere) for a long time, and most systems no longer have an intermediate state during boot in which they have only `/`, but not `/usr`, mounted. Booting hosts through that intermediate state is not systematically tested in Debian anymore. -* another use-case is to be able to share an identical `/usr` over a network link; hence booting an initramfs, mounting a local `/`, then mounting `/usr` over the network. It seems that an initramfs with everything needed to mount a filesystem over a network link directly actually has a smaller footprint. +* another use-case is to share system files from `/usr` between hosts (over a network link) or containers (locally) which use different data or configuration. Having all software under `/usr` (instead of spread between `/` and `/usr`) makes the centralized update and the sharing easier. * the packaging infrastructure to install files outside of `/usr` is not standard and represents technical debt: * given its status as remnant "folklore", the distinction between what _needs_ to be shipped in `/` and what can stay in `/usr` is often interpreted arbitrarily; * allowing shipment of identically-named libraries or binaries in different paths can confuse common understanding of paths precedence. -- 2.39.2