Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var
On Sun, 4 Jun 2023 at 12:02, Sean Whitton <spwhitton@spwhitton.name> wrote:
>
> Hello,
>
> On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
>
> > I've done an initial attempt to define the wording, although I'm sure
> > it will need quite a few changes. Attached as a patch, and also
> > available on Salsa:
> >
> > https://salsa.debian.org/bluca/policy/-/commits/tmpfiles
> >
> > Happy to move/reword/change/enhance as required.
>
> Thanks.
>
> > For now I've kept only a mention of the 'systemd-tmpfiles' virtual
> > package. As maintainers we would really prefer if the 'main'
> > implementation is pulled in whenever possible. When a minimal
> > installation is desired (ie, a minbase), it is possible to manually
> > specify the -standalone variant.
> >
> > This was a controversial point last year, see:
> >
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1017441
>
> Hmm. I don't have personal experience with this sort of thing, but
> based on some of the examples in that bug, it seems like doing this
> could cause apt to change people's systems around in ways they strongly
> disprefer. What you propose seems like it could cause unpleasant
> surprises.
Only due to bugs in said other packages, or if the wrong commands are
passed to apt/aptitude/etc.
> > We could even decide that no dependency is added at all by dh, and
> > instead the build tool needs to decide if it's building an image where
> > tmpfiles snippets need to be ran, and if so pull in the preferred
> > alternative.
>
> This is a highly inspecific response, but: aren't things expressed by
> dependencies generally less work for everyone than more special cases to
> be handled by each build tool?
Well, sure, but at some point it's either one or the other: set up the
dependencies so that the default case (which in debian is systemd)
works out of the box and the right thing happens magically, and people
who want to use non-default init systems (which are supported for the
purpose of "experimenting and exploring alternatives") will need to
fix their packages and provide the right instructions to apt, or no
dependency is set at all and bootstrapping/image building/etc tools
need to adapt and manually pull the right tools at the right time.
I'm in favour of the first one, to be clear, but I am open to the
second one for policy if that's what you prefer, and say nothing, in
the interest of moving forward with the change, and at least codify
how things should look like, leaving the low-level arrangements out of
it.
Kind regards,
Luca Boccassi
Reply to: