Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote:
> Bill Allombert <ballombe@debian.org> writes:
> > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> >> On Sep 17, Russ Allbery <rra@debian.org> wrote:
>
> >>> (I am a little confused by this wording, but I think what you're
> >>> saying is that /usr is encrypted and read-only, and /var is recreated
> >>> on each boot. That at least is my understanding of the pattern that
> >>> you're trying to enable.)
>
> >> The general idea is to be able to create /var on the first boot.
>
> > Does not that would break users expectation that the system image
> > contains /var before the first boot ?
>
> > A lot of things in /var are caches that are mostly instance-independent
> > and can be prefilled, but for that, users expect a minimal directory
> > hierarchy to be present before first boot.
>
> Not that I think we're particularly close to achieving this design
> currently (and to be clear we haven't decided we're working towards this
> yet), but while I understand why a user would have that expectation today,
> I'm not sure why it would practically matter. If all of that directory
> structure appears on first boot, and no static data is stored in /var,
> what use case requires the directory structure already exist in /var
> before the first boot?
As I said, filling the caches in /var/cache. For that they need to
exist with correct ownership and permissions.
Most of the cache in /var/cache/ (some are in /var/lib actually)
do not depend on the host configuration, and can be regenerated/redownloaded as
needed, but not for free.
For example you might want to populate
/var/cache/apt/archives/ with the debs you need install later on (for example
for a pbuilder-like system), populate /var/lib/texmf/fonts/ with your fonts, or
even populate /var/www with your website, etc.
Cheers,
--
Bill. <ballombe@debian.org>
Imagine a large red swirl here.
Reply to: