XPost: linux.debian.bugs.dist
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
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)