Re: /usr/-only image
On Mon, 11 Sept 2023 at 15:09, Simon McVittie <smcv@debian.org> wrote:
>
> On Mon, 11 Sep 2023 at 08:58:09 +0200, Gioele Barabucci wrote:
> > An even bigger prerequisite is that many upstream projects does not yet
> > support working without /etc or (orthogonally) reading their default
> > configuration from /usr.
>
> I agree that an "upstream first" approach is good here - even if we might
> want Debian maintainers to backport upstream changes that haven't made it
> into a release yet. Loading defaults from /usr is a behaviour change, and
> many downstream maintainers are (IMO correctly) reluctant to make
> Debian-specific behaviour changes for things that would ideally go
> upstream but have not yet been accepted upstream, because that carries a
> risk of the change never happening upstream and the Debian delta therefore
> becoming permanent.
>
> There are a couple of inter-related things here, which might make sense
> to treat as separate topics.
>
> Integration hooks
> =================
>
> Quite a lot of packages have some sort of integration hook, where package A
> installs a file in a location "owned" by package B, to make the two
> packages integrate nicely together. It's best if we can change package B
> to load these integration hooks from /usr, and then systematically change
> all examples of package A to install there.
>
> Because this involves a large number of often trivially small files,
> working on this will probably have the largest impact on the number of
> files in /etc that would need special management for anyone who wants to
> use a /usr-only filesystem image.
>
> For instance, dbus-daemon (and other D-Bus implementations like
> dbus-broker) used to require system services to install a snippet into
> /etc/dbus-1/system.d. It's now deprecated for packages to install files
> into that directory, and instead, they should install into
> /usr/share/dbus-1/system.d, reserving /etc/dbus-1/system.d for sysadmin
> overrides.
>
> The steps to take here are:
>
> 1. Change package B to load from /usr in addition to /etc. This should
> usually be done upstream, because it's a behaviour change.
> (For instance where B = dbus-daemon, we did this in 2015.)
> If multiple packages all load from the same location (like dbus-daemon
> and dbus-broker) then all of them need this change.
>
> 2. For each package A, move the integration/configuration snippet from
> /etc to /usr. This should ideally be done upstream too, but it's usually
> straightforward (low maintenance cost) to do this in our packaging,
> and it doesn't necessarily *need* to happen upstream.
>
> Configuration defaults
> ======================
>
> Some packages rely on their own configuration existing in /etc. For these
> packages, ideally they'd try loading from /etc as highest priority, but
> fall back to /usr as a lower-priority location. This is a
> package-by-package change, and probably best achieved upstream.
Actually this upstream work has already been happening, for years,
spearheaded by SUSE, who are the authors of libeconf
(https://github.com/openSUSE/libeconf) which provides a turn key
solution to implement this pattern of config loading.
In fact, Marco yesterday told me the only blocker to boot a minimal
Debian image with only /usr is PAM, and that's exclusively because of
downstream-specific changes - upstream not only has supported the
hermetic-usr config model for years, but the upstream maintainer is
one of the main drivers of the generic effort at SUSE.
Given this, it seems to me the first order of business should be to
get our downstream PAM sorted first.
In the meanwhile, we discussed this issue both at this week's
Image-Based Linux Summit and ASG2023, and I've got AIs on me to make
the hermetic-usr/libeconf format into a standalone spec under
uapi-group.org, and to see if we can get a cross-distro tracker for
the common upstreams (required for minimal/reduced images, it will
never be a 100% coverage affair as the problem space is too vast) that
still need changes. I'll try to get to those next week.
Reply to: