Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1148719 > unrolled thread

Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-04 13:20 +0200
    Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-04 16:10 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 02:40 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-05 11:00 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 13:20 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 17:50 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 18:20 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Bill Allombert <ballombe@debian.org> - 2023-06-13 18:20 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Marco d'Itri <md@Linux.IT> - 2023-06-13 18:40 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Ansgar <ansgar@43-1.org> - 2023-06-13 19:50 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 20:10 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 18:40 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 20:20 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 21:00 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 21:10 +0200
                    Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 21:30 +0200
                      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Thorsten Glaser <t.glaser@tarent.de> - 2023-06-13 23:20 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-05 11:20 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-05 13:20 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Helmut Grohne <helmut@subdivi.de> - 2023-06-05 14:20 +0200
      Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-06 13:10 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-06 14:10 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-07 05:50 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Simon McVittie <smcv@debian.org> - 2023-06-07 12:40 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-07 13:00 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-07 12:40 +0200
        Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Mark Hindley <mark@hindley.org.uk> - 2023-06-13 15:10 +0200
          Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Mark Hindley <mark@hindley.org.uk> - 2023-06-13 19:10 +0200
            Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 20:00 +0200
              Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-13 21:50 +0200
                Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Russ Allbery <rra@debian.org> - 2023-06-13 22:00 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Luca Boccassi <bluca@debian.org> - 2023-06-13 22:10 +0200
                  Bug#945269: debian-policy: packages should use tmpfiles.d(5) to create directories below /var Ansgar <ansgar@43-1.org> - 2023-06-13 22:30 +0200

Page 1 of 2  [1] 2  Next page →

#1148719 — 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

[toc] | [next] | [standalone]

#1148743

(Newly cc'd elogind maintainers: Please see #945269 for context)

On Sun, 04 Jun 2023 at 12:15:41 +0100, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 at 12:02, Sean Whitton <spwhitton@spwhitton.name> wrote:
> > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
> > > 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.

I think one way or another, if anyone is going to set a package-level
dependency on systemd-tmpfiles, the first (preferred) dependency needs to
be on either a concrete provider (systemd or systemd-tmpfiles-standalone
in this case), or a default-systemd-tmpfiles virtual package
that only has one provider per architecture (which is the way
{default-,}dbus-{system,session}-bus are handled). Otherwise, you
can get a non-deterministic choice of default implementation, which
seems strictly worse than either depending on systemd or depending on
systemd-tmpfiles-standalone - if you're unlucky, it can have all the
disadvantages of either one of those.

So I think the only realistic options for packages that hard-require
this functionality (not all do) are:

1. Depends: systemd | systemd-tmpfiles
2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
3. Depends: default-systemd-tmpfiles | systemd-tmpfiles

(where the third one is equivalent to one of the first two, depending on
how default-systemd-tmpfiles was implemented), possibly with some more
less-preferred options between the first "|" and the virtual-package
fallback.

I also think that Policy shouldn't be recommending this interface without
also being able to give guidance on what an appropriate dependency would
look like, because if some packages choose (1.) and some choose (2.),
again we'll get a non-deterministic result, depending on which packages
you happen to install first and what their maintainers think; and I don't
want individual services' maintainers to be required to constantly argue
whether (1.) or (2.) is better.

In #1017441 the debhelper maintainers declined to generate such a
dependency, but even if they had wanted to generate it centrally, we'd
have the same distro-integration considerations about saying what the
right dependency would look like.

Before describing pros and cons of those options in different scenarios,
I want to reiterate that installing the systemd package (which contains
the default/recommended implementation of the systemd-tmpfiles interface)
does not imply using systemd as an init system, and everywhere in this
message that I have said "systemd", I specifically mean the systemd
package and not systemd-as-pid-1.

From the point of view of init systems, I think the interesting scenarios
are:

A. systemd package installed (typically via systemd-sysv)
B. non-systemd init system (typically sysvinit) and no systemd package
C. no init system at all (typically in Docker or a chroot)

For (A.), there is no ambiguity: systemd is installed and provides the
tmpfiles interface, and everything is fine. Any dependency sequence ((1.),
(2.) or (3.) above) should give us the result we want. The only problem
scenario I can think of for (A.) with (2.) is:

- a package (let's say foo-service) has chosen (2.) and so depends on
  systemd-tmpfiles-standalone | systemd-tmpfiles
- we install a base system with neither foo-service nor systemd
  - this must be a minbase debootstrap or similar, because a default
    debootstrap already includes systemd-sysv
- we install foo-service first, without systemd
  - systemd-tmpfiles-standalone is pulled in
- afterwards, we install systemd (via the init metapackage and
  systemd-sysv, or directly)
  - desired result: systemd-tmpfiles-standalone is removed and replaced by
    systemd
  - actual result: apt's heuristic might have difficulty realising that
    it needs to do that

I would have expected that anyone wanting an environment with an init
system is more likely to include it in the bootstrap or in the first
batch of post-bootstrap additions than to install it later, but maybe
that's wrong? Or are there other problem scenarios here?

I'll come back to (B.), non-default init, in a moment.

No init system at all, (C.), can only happen when starting with a
minbase debootstrap or equivalent (because a default debootstrap
includes the init metapackage due to its Priority: required). In
this scenario it *usually* doesn't really matter whether we
install systemd or systemd-tmpfiles-standalone. systemd is somewhat
larger, so container/chroot maintainers might prefer to install
systemd-tmpfiles-standalone for size optimization, but either one should
give us correct results. What I'm hearing from Luca and other systemd
maintainers is that the systemd team would prefer this scenario to
get the (much more widely-tested) full-sized systemd package, unless
the container/chroot maintainer has explicitly taken steps to get a
non-default implementation for reduced on-disk size. Is that correct?
As far as I can see, either (1.) or (2.) would achieve that in practice,
again because a default debootstrap includes systemd, and I think asking
for minbase should be counted as an example of explicitly taking steps
to get a reduced on-disk size.

One possible problem scenario for (C.) with (2.) is that if we start from
minbase but then some other dependency pulls in the full systemd package
anyway (perhaps as a way to get systemd.pc into a buildd chroot, or as
a dependency of systemd-container) then we will have the same problem
that I outlined for (A.): apt's heuristic needs to be able to realise
that removing systemd-tmpfiles-standalone to be replaced by systemd
is a valid solution, and because problem resolution is a heuristic,
there's a chance that that won't happen.

Now the elephant in the room, (B.): non-default (non-systemd) init. The
main problem with (1.), having systemd as the first (preferred)
dependency, is that it is mutually exclusive with elogind (because the
systemd maintainers are not willing to support systemd tools being
co-installed with a non-systemd reimplementation of logind, which
is an entirely reasonable choice IMO), but users of non-systemd init
systems rely on elogind as a dependency of desktop environments and
other higher-level functionality. This gives us #1014805, #1016006,
#1017441 and similar issues: if a user of non-systemd init has not
yet installed any implementation of the tmpfiles interface, when they
upgrade a package to a version that depends on systemd-tmpfiles, it is
entirely possible that apt's heuristic will propose installing systemd and
therefore removing elogind and the desktop environment, instead of the
result the user would presumably have preferred, which is installation
of systemd-tmpfiles-standalone. Obviously that's not what we want to
happen. The situation is rare and only arises with a non-default init,
but the failure mode is very bad.

It is technically correct to say (as was said on #1014805, etc.) that
installing the systemd package does not preclude experiments with
non-default init systems, but in practice that reasoning only holds for
relatively small software stacks: if you want a desktop environment, in
practice you'll likely need a logind implementation, which means either
the full systemd stack with systemd-logind (which requires systemd
as pid 1), or elogind (which is mutually exclusive with systemd). I
am personally happy with systemd as pid 1 and so I see no reason to
install elogind myself, but it is available as a non-default option,
and we should be honest about the impact of related decisions on the
ability to make use of that option.

A couple of mitigations for the problem case I described above were
suggested on #1014805 and #1016006:

- On #1014805, Michael Biebl suggested having sysvinit-core pull in
  systemd-tmpfiles-standalone via Depends (or maybe Recommends).
  Adam Borowski objected to this for two reasons:
  - sysvinit-core does not actually require any tmpfiles implementation,
    and it is only the individual services that might require one, so a
    dependency there (for A.) doesn't have much theoretical justification;
  - he felt that adding ~ 450K to minimal chroots (for C.) is too much.

- On #1016006, Mark Hindley suggested making systemd-standalone-tmpfiles
  the first (preferred) alternative in the or-group, which is what I
  called (2.) above. I haven't seen a rebuttal for that; did the systemd
  maintainers reject this because it would have the side-effect of always
  installing systemd-standalone-tmpfiles in the init-less scenario (C.),
  or were there other reasons?

Another possible mitigation which I haven't previously seen proposed
is giving *elogind* a Depends or Recommends on systemd-*-standalone.
I think that would work to mitigate the failure mode with (1.) and (B.),
and the installed-size argument seems less interesting here because the
sort of systems that require elogind are already much larger anyway.
Would the elogind maintainers be willing to consider this? Does anyone
see a reason why it wouldn't work?

Taking a step back from the specifics of -tmpfiles for a moment:

As a maintainer of system services, I would not be at all happy with
expecting the maintainer of every system service that requires tmpfiles
to have this conversation again and again. Obviously as a technical
committee member and occasional Policy contributor, I've chosen to take
on some of the burden of decisions like this one; but when I'm working
on dbus or polkitd or even openarena-server, I should be able to follow
a project decision, and be reasonably confident that I won't get angry
RC bug reports about it (and if I do, I should be able to refer the bug
reporter to a project decision instead of having to re-litigate it).
Putting this sort of thing on individual package maintainers seems like
a recipe for making it no longer fun to maintain a package.

I would like to be able to rely on sysusers.d for declarative creation
of system users in future, and that will make correct dependency handling
more important than it is now for tmpfiles.d, because unlike tmpfiles.d,
packages that own a system user often *do* have a hard dependency
on that system user being created in the postinst (and as a result,
dh_installsysusers in compat level >= 14 generates a dependency, unlike
dh_installtmpfiles).

At the moment, mostly as an experiment, polkitd depends on
adduser | systemd-sysusers (and it can't rely on dh_installsysusers
anyway, as far as I can see, as a result of some tricky sequencing
considerations in the postinst), but that's a workaround and I would
prefer to be using sysusers unconditionally.

If we can't get a consensus here, one option would be to refer the
question to the technical committee.

> > > We could even decide that no dependency is added at all by dh

For the record, that is the decision that the debhelper maintainers made
for tmpfiles.d in #1017441, on the basis that processing tmpfiles.d is
often a nice-to-have rather than a mandatory dependency: for example,
dbus has a tmpfiles.d snippet but will work correctly without it, with
only slightly reduced functionality.

However, debhelper does add a dependency for sysusers.d snippets, which
are out-of-scope for this particular Policy bug, but are "the same shape"
as tmpfiles.d in terms of how they're handled by systemd and how they
will need to be handled by non-default init systems.

> 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

Luca, I see you're effectively ruling out what I described in
(2.) above. Is that because of the problem scenario I outlined above with
late installation of systemd potentially having difficulty with replacing
systemd-tmpfiles-standalone, or are there other problem scenarios that
you have in mind?

Thanks,
    smcv

[toc] | [prev] | [next] | [standalone]

#1148771

On Sun, 4 Jun 2023 at 14:56, Simon McVittie <smcv@debian.org> wrote:
>
> (Newly cc'd elogind maintainers: Please see #945269 for context)
>
> On Sun, 04 Jun 2023 at 12:15:41 +0100, Luca Boccassi wrote:
> > On Sun, 4 Jun 2023 at 12:02, Sean Whitton <spwhitton@spwhitton.name> wrote:
> > > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
> > > > 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.
>
> I think one way or another, if anyone is going to set a package-level
> dependency on systemd-tmpfiles, the first (preferred) dependency needs to
> be on either a concrete provider (systemd or systemd-tmpfiles-standalone
> in this case), or a default-systemd-tmpfiles virtual package
> that only has one provider per architecture (which is the way
> {default-,}dbus-{system,session}-bus are handled). Otherwise, you
> can get a non-deterministic choice of default implementation, which
> seems strictly worse than either depending on systemd or depending on
> systemd-tmpfiles-standalone - if you're unlucky, it can have all the
> disadvantages of either one of those.
>
> So I think the only realistic options for packages that hard-require
> this functionality (not all do) are:
>
> 1. Depends: systemd | systemd-tmpfiles
> 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
> 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles
>
> (where the third one is equivalent to one of the first two, depending on
> how default-systemd-tmpfiles was implemented), possibly with some more
> less-preferred options between the first "|" and the virtual-package
> fallback.
>
> I also think that Policy shouldn't be recommending this interface without
> also being able to give guidance on what an appropriate dependency would
> look like, because if some packages choose (1.) and some choose (2.),
> again we'll get a non-deterministic result, depending on which packages
> you happen to install first and what their maintainers think; and I don't
> want individual services' maintainers to be required to constantly argue
> whether (1.) or (2.) is better.
>
> In #1017441 the debhelper maintainers declined to generate such a
> dependency, but even if they had wanted to generate it centrally, we'd
> have the same distro-integration considerations about saying what the
> right dependency would look like.
>
> Before describing pros and cons of those options in different scenarios,
> I want to reiterate that installing the systemd package (which contains
> the default/recommended implementation of the systemd-tmpfiles interface)
> does not imply using systemd as an init system, and everywhere in this
> message that I have said "systemd", I specifically mean the systemd
> package and not systemd-as-pid-1.
>
> >From the point of view of init systems, I think the interesting scenarios
> are:
>
> A. systemd package installed (typically via systemd-sysv)
> B. non-systemd init system (typically sysvinit) and no systemd package
> C. no init system at all (typically in Docker or a chroot)
>
> For (A.), there is no ambiguity: systemd is installed and provides the
> tmpfiles interface, and everything is fine. Any dependency sequence ((1.),
> (2.) or (3.) above) should give us the result we want. The only problem
> scenario I can think of for (A.) with (2.) is:
>
> - a package (let's say foo-service) has chosen (2.) and so depends on
>   systemd-tmpfiles-standalone | systemd-tmpfiles
> - we install a base system with neither foo-service nor systemd
>   - this must be a minbase debootstrap or similar, because a default
>     debootstrap already includes systemd-sysv
> - we install foo-service first, without systemd
>   - systemd-tmpfiles-standalone is pulled in
> - afterwards, we install systemd (via the init metapackage and
>   systemd-sysv, or directly)
>   - desired result: systemd-tmpfiles-standalone is removed and replaced by
>     systemd
>   - actual result: apt's heuristic might have difficulty realising that
>     it needs to do that
>
> I would have expected that anyone wanting an environment with an init
> system is more likely to include it in the bootstrap or in the first
> batch of post-bootstrap additions than to install it later, but maybe
> that's wrong? Or are there other problem scenarios here?
>
> I'll come back to (B.), non-default init, in a moment.
>
> No init system at all, (C.), can only happen when starting with a
> minbase debootstrap or equivalent (because a default debootstrap
> includes the init metapackage due to its Priority: required). In
> this scenario it *usually* doesn't really matter whether we
> install systemd or systemd-tmpfiles-standalone. systemd is somewhat
> larger, so container/chroot maintainers might prefer to install
> systemd-tmpfiles-standalone for size optimization, but either one should
> give us correct results. What I'm hearing from Luca and other systemd
> maintainers is that the systemd team would prefer this scenario to
> get the (much more widely-tested) full-sized systemd package, unless
> the container/chroot maintainer has explicitly taken steps to get a
> non-default implementation for reduced on-disk size. Is that correct?
> As far as I can see, either (1.) or (2.) would achieve that in practice,
> again because a default debootstrap includes systemd, and I think asking
> for minbase should be counted as an example of explicitly taking steps
> to get a reduced on-disk size.
>
> One possible problem scenario for (C.) with (2.) is that if we start from
> minbase but then some other dependency pulls in the full systemd package
> anyway (perhaps as a way to get systemd.pc into a buildd chroot, or as
> a dependency of systemd-container) then we will have the same problem
> that I outlined for (A.): apt's heuristic needs to be able to realise
> that removing systemd-tmpfiles-standalone to be replaced by systemd
> is a valid solution, and because problem resolution is a heuristic,
> there's a chance that that won't happen.
>
> Now the elephant in the room, (B.): non-default (non-systemd) init. The
> main problem with (1.), having systemd as the first (preferred)
> dependency, is that it is mutually exclusive with elogind (because the
> systemd maintainers are not willing to support systemd tools being
> co-installed with a non-systemd reimplementation of logind, which
> is an entirely reasonable choice IMO), but users of non-systemd init
> systems rely on elogind as a dependency of desktop environments and
> other higher-level functionality. This gives us #1014805, #1016006,
> #1017441 and similar issues: if a user of non-systemd init has not
> yet installed any implementation of the tmpfiles interface, when they
> upgrade a package to a version that depends on systemd-tmpfiles, it is
> entirely possible that apt's heuristic will propose installing systemd and
> therefore removing elogind and the desktop environment, instead of the
> result the user would presumably have preferred, which is installation
> of systemd-tmpfiles-standalone. Obviously that's not what we want to
> happen. The situation is rare and only arises with a non-default init,
> but the failure mode is very bad.
>
> It is technically correct to say (as was said on #1014805, etc.) that
> installing the systemd package does not preclude experiments with
> non-default init systems, but in practice that reasoning only holds for
> relatively small software stacks: if you want a desktop environment, in
> practice you'll likely need a logind implementation, which means either
> the full systemd stack with systemd-logind (which requires systemd
> as pid 1), or elogind (which is mutually exclusive with systemd). I
> am personally happy with systemd as pid 1 and so I see no reason to
> install elogind myself, but it is available as a non-default option,
> and we should be honest about the impact of related decisions on the
> ability to make use of that option.
>
> A couple of mitigations for the problem case I described above were
> suggested on #1014805 and #1016006:
>
> - On #1014805, Michael Biebl suggested having sysvinit-core pull in
>   systemd-tmpfiles-standalone via Depends (or maybe Recommends).
>   Adam Borowski objected to this for two reasons:
>   - sysvinit-core does not actually require any tmpfiles implementation,
>     and it is only the individual services that might require one, so a
>     dependency there (for A.) doesn't have much theoretical justification;
>   - he felt that adding ~ 450K to minimal chroots (for C.) is too much.

As tmpfiles.d becomes the official format for declarative setups,
which is very much desired in order to be able to remove vast
quantities of maintainer scripts, sysvinit or adjacent packages will
eventually need it. It doesn't have to be sysvinit-core, it can be
elogind as you say later or anything else in that dependency chain.

> - On #1016006, Mark Hindley suggested making systemd-standalone-tmpfiles
>   the first (preferred) alternative in the or-group, which is what I
>   called (2.) above. I haven't seen a rebuttal for that; did the systemd
>   maintainers reject this because it would have the side-effect of always
>   installing systemd-standalone-tmpfiles in the init-less scenario (C.),
>   or were there other reasons?

Yes, we very much want the preferred package to be used in almost all
scenarios, as it makes maintenance easier and more straightforward.
Our time is worth more than 80K or whatever it is of disk space in a
throw-away container.

> Another possible mitigation which I haven't previously seen proposed
> is giving *elogind* a Depends or Recommends on systemd-*-standalone.
> I think that would work to mitigate the failure mode with (1.) and (B.),
> and the installed-size argument seems less interesting here because the
> sort of systems that require elogind are already much larger anyway.
> Would the elogind maintainers be willing to consider this? Does anyone
> see a reason why it wouldn't work?

That seems like it should work just fine as mentioned above.

> Taking a step back from the specifics of -tmpfiles for a moment:
>
> As a maintainer of system services, I would not be at all happy with
> expecting the maintainer of every system service that requires tmpfiles
> to have this conversation again and again. Obviously as a technical
> committee member and occasional Policy contributor, I've chosen to take
> on some of the burden of decisions like this one; but when I'm working
> on dbus or polkitd or even openarena-server, I should be able to follow
> a project decision, and be reasonably confident that I won't get angry
> RC bug reports about it (and if I do, I should be able to refer the bug
> reporter to a project decision instead of having to re-litigate it).
> Putting this sort of thing on individual package maintainers seems like
> a recipe for making it no longer fun to maintain a package.
>
> I would like to be able to rely on sysusers.d for declarative creation
> of system users in future, and that will make correct dependency handling
> more important than it is now for tmpfiles.d, because unlike tmpfiles.d,
> packages that own a system user often *do* have a hard dependency
> on that system user being created in the postinst (and as a result,
> dh_installsysusers in compat level >= 14 generates a dependency, unlike
> dh_installtmpfiles).
>
> At the moment, mostly as an experiment, polkitd depends on
> adduser | systemd-sysusers (and it can't rely on dh_installsysusers
> anyway, as far as I can see, as a result of some tricky sequencing
> considerations in the postinst), but that's a workaround and I would
> prefer to be using sysusers unconditionally.
>
> If we can't get a consensus here, one option would be to refer the
> question to the technical committee.
>
> > > > We could even decide that no dependency is added at all by dh
>
> For the record, that is the decision that the debhelper maintainers made
> for tmpfiles.d in #1017441, on the basis that processing tmpfiles.d is
> often a nice-to-have rather than a mandatory dependency: for example,
> dbus has a tmpfiles.d snippet but will work correctly without it, with
> only slightly reduced functionality.
>
> However, debhelper does add a dependency for sysusers.d snippets, which
> are out-of-scope for this particular Policy bug, but are "the same shape"
> as tmpfiles.d in terms of how they're handled by systemd and how they
> will need to be handled by non-default init systems.
>
> > 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
>
> Luca, I see you're effectively ruling out what I described in
> (2.) above. Is that because of the problem scenario I outlined above with
> late installation of systemd potentially having difficulty with replacing
> systemd-tmpfiles-standalone, or are there other problem scenarios that
> you have in mind?

Yes, that's one of the issues, but more broadly as mentioned we want
the same setup to be used everywhere for ease of maintenance purposes.
If it is useful, adding a "default-tmpfiles" or so virtual package
would be fine by me - but with the kfreebsd port being retired soon,
and i386 (for hurd) going the way of the dodo, I'm not sure it would
be very useful? I don't think it would be a problem to add it, if it
turns out to be of use though.

Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1148786

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> If it is useful, adding a "default-tmpfiles" or so virtual package
> would be fine by me - but with the kfreebsd port being retired soon,
> and i386 (for hurd) going the way of the dodo, I'm not sure it would
> be very useful? I don't think it would be a problem to add it, if it
> turns out to be of use though.

What this would look like, in src:systemd:

    Package: systemd
    Provides: default-systemd-tmpfiles, systemd-tmpfiles

    Package: systemd-standalone-tmpfiles
    Provides: systemd-tmpfiles

(or maybe the other way round, depending what conclusion we come to on
the choice between (1.) and (2.)), and then in dependent packages:

    Package: foo-service
    Depends: default-systemd-tmpfiles | systemd-tmpfiles

The benefits of that over having foo-service depend directly on
"systemd | systemd-tmpfiles" or
"systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor, but the
cost is also fairly minor; and if we want this, we should set it up
*before* lots of packages start adding a dependency on the -tmpfiles or
-sysusers interfaces. The benefits I see are:

- if we find out that the dependency we first added is a practical problem
  for whatever reason, we can swap the default with a src:systemd upload,
  without needing multiple maintainers to touch all the dependent packages;

- if we get a useful non-Linux port (admittedly this looks increasingly
  unlikely) which cannot compile src:systemd, then their reimplementation
  of these interfaces can have Provides: default-systemd-tmpfiles on that
  architecture, without affecting Linux architectures
  (the same way dbus-x11 Provides default-dbus-session-bus on non-Linux
  ports, even though it's dbus-user-session that Provides the virtual
  package on Linux)

    smcv

[toc] | [prev] | [next] | [standalone]

#1148796

[Multipart message — attachments visible in raw view] — view raw

On Mon, 5 Jun 2023 09:53:39 +0100 Simon McVittie <smcv@debian.org>
wrote:
> On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> > If it is useful, adding a "default-tmpfiles" or so virtual package
> > would be fine by me - but with the kfreebsd port being retired
soon,
> > and i386 (for hurd) going the way of the dodo, I'm not sure it
would
> > be very useful? I don't think it would be a problem to add it, if
it
> > turns out to be of use though.
> 
> What this would look like, in src:systemd:
> 
>     Package: systemd
>     Provides: default-systemd-tmpfiles, systemd-tmpfiles
> 
>     Package: systemd-standalone-tmpfiles
>     Provides: systemd-tmpfiles
> 
> (or maybe the other way round, depending what conclusion we come to
on
> the choice between (1.) and (2.)), and then in dependent packages:
> 
>     Package: foo-service
>     Depends: default-systemd-tmpfiles | systemd-tmpfiles
> 
> The benefits of that over having foo-service depend directly on
> "systemd | systemd-tmpfiles" or
> "systemd-standalone-tmpfiles | systemd-tmpfiles" are fairly minor,
but the
> cost is also fairly minor; and if we want this, we should set it up
> *before* lots of packages start adding a dependency on the -tmpfiles
or
> -sysusers interfaces. The benefits I see are:
> 
> - if we find out that the dependency we first added is a practical
problem
>   for whatever reason, we can swap the default with a src:systemd
upload,
>   without needing multiple maintainers to touch all the dependent
packages;
> 
> - if we get a useful non-Linux port (admittedly this looks
increasingly
>   unlikely) which cannot compile src:systemd, then their
reimplementation
>   of these interfaces can have Provides: default-systemd-tmpfiles on
that
>   architecture, without affecting Linux architectures
>   (the same way dbus-x11 Provides default-dbus-session-bus on non-
Linux
>   ports, even though it's dbus-user-session that Provides the virtual
>   package on Linux)

Sure, that sounds reasonable and simple enough to do, no objection from
me.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1149497

On Mon, 5 Jun 2023, Simon McVittie wrote:

>No init system at all, (C.), can only happen when starting with a
>minbase debootstrap or equivalent (because a default debootstrap
>includes the init metapackage due to its Priority: required). In
>this scenario it *usually* doesn't really matter whether we
>install systemd or systemd-tmpfiles-standalone. systemd is somewhat

This is not quite true; there is one really important use case:
chroots. I have multiple chroots (sid, stretch, buster) on one
of my bullseye systems which I use with schroot, but that could
just as well be any other chroot, to run individual software in
it. They are, as is proper, configured to not run any services
(via policy-rc.d).

>I also think that Policy shouldn't be recommending this interface without

Therefore I belive that Policy ought to *not* recommend any
solution that depends on starting dæmons or init scripts to
create temporary files/directories that are necessary for
programs to work.

>- if we get a useful non-Linux port (admittedly this looks increasingly
>  unlikely) which cannot compile src:systemd, then their reimplementation

hurd-amd64 is just shy of being uploaded; work on Debian GNU/Hurd
is active and things seem to look good on that front. (The pools
for hurd-amd64 have just been created a week or two ago.)

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1149502

On Tue, 13 Jun 2023, Bill Allombert wrote:

>I agree, chroots are important to consider, and the system should not
>make assumptions how and why there are used.

Thanks!

>Conversely, sometimes I need to use chroots to test init scripts.
>start-stop-daemon should not refuse to run in a chroot if policy-rc.d
>allows it.

TTBOMK this works-ish. It certainly starts and stops things, but if
you have the same thing running outside of the chroot, interference
may happen. You’ll probably want a separate pid namespace (I think)
at least, and make sure that, when leaving the chroot, everything
started in it is in fact terminated; sometimes, things like to keep
hanging around. This is easier to manage with VMs or (probably; I
don’t like to use them myself) container-ish thingies.

In my schroot setup I used to start a vncserver in a persistent
chroot back when my main system was x32 and vncserver didn’t like
that nor was coïnstallable (hence the i386 chroot).

My “enter a Debian chroot” script, to use e.g. with a Grml live ISO
to fix the bootloader (or to work under qemu-user with an RPi µSD
image before moving it into the embedded machine), certainly tries
hard to create a policy-rc.d to disable dæmon starting should the
user need to install packages, so it generally will work.
https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=shellsnippets/shellsnippets.git;a=blob;f=posix/sysadmin/debchroot.sh;hb=HEAD
in case someone’s interested, it’s more complete than grml-chroot.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1149504

On Tue, Jun 13, 2023 at 05:43:17PM +0200, Thorsten Glaser wrote:
> On Mon, 5 Jun 2023, Simon McVittie wrote:
> 
> >No init system at all, (C.), can only happen when starting with a
> >minbase debootstrap or equivalent (because a default debootstrap
> >includes the init metapackage due to its Priority: required). In
> >this scenario it *usually* doesn't really matter whether we
> >install systemd or systemd-tmpfiles-standalone. systemd is somewhat
> 
> This is not quite true; there is one really important use case:
> chroots. I have multiple chroots (sid, stretch, buster) on one
> of my bullseye systems which I use with schroot, but that could
> just as well be any other chroot, to run individual software in
> it. They are, as is proper, configured to not run any services
> (via policy-rc.d).

I agree, chroots are important to consider, and the system should not make
assumptions how and why there are used.

Conversely, sometimes I need to use chroots to test init scripts.
start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
it.

Cheers,
Bill.

[toc] | [prev] | [next] | [standalone]

#1149507

[Multipart message — attachments visible in raw view] — view raw

On Jun 13, Bill Allombert <ballombe@debian.org> wrote:

> Conversely, sometimes I need to use chroots to test init scripts.
> start-stop-daemon should not refuse to run in a chroot if policy-rc.d allows
> it.
I suggest that you try systemd-nspawn for this purpose.

-- 
ciao,
Marco

[toc] | [prev] | [next] | [standalone]

#1149517

On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
> On Jun 13, Bill Allombert <ballombe@debian.org> wrote:
> 
> > Conversely, sometimes I need to use chroots to test init scripts.
> > start-stop-daemon should not refuse to run in a chroot if policy-
> > rc.d allows
> > it.
> I suggest that you try systemd-nspawn for this purpose.
> 

Or podman or docker or various other things.

Plain chroots and an unclean environment which violates various
assumptions system startup scripts make are not a great way to test
stuff.

Ansgar

[toc] | [prev] | [next] | [standalone]

#1149522

Ansgar <ansgar@43-1.org> writes:
> On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
>> On Jun 13, Bill Allombert <ballombe@debian.org> wrote:

>>> Conversely, sometimes I need to use chroots to test init scripts.
>>> start-stop-daemon should not refuse to run in a chroot if policy-
>>> rc.d allows
>>> it.

>> I suggest that you try systemd-nspawn for this purpose.

> Or podman or docker or various other things.

> Plain chroots and an unclean environment which violates various
> assumptions system startup scripts make are not a great way to test
> stuff.

Unless I'm very mistaken about how dh_installtmpfiles and systemd-tmpfiles
works (possible, I guess), I don't think we need to have this argument in
this bug.  If I am right in assuming that nothing about this proposal will
change how chroots work, arguing with people about why they use chroots is
just going to add heat without any light.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149508

Thorsten Glaser <t.glaser@tarent.de> writes:

> Therefore I belive that Policy ought to *not* recommend any solution
> that depends on starting dæmons or init scripts to create temporary
> files/directories that are necessary for programs to work.

This is handled by this proposal, no?  That's the point of requiring
integration with maintainer scripts (via triggers or direct invocation).
My understanding is that this is exactly what dh_installtmpfiles already
does, via generating an explicit call to systemd-tmpfiles --create.

Or am I missing something?

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149525

On Tue, 13 Jun 2023, Russ Allbery wrote:

>Thorsten Glaser <t.glaser@tarent.de> writes:
>
>> Therefore I belive that Policy ought to *not* recommend any solution
>> that depends on starting dæmons or init scripts to create temporary
>> files/directories that are necessary for programs to work.
>
>This is handled by this proposal, no?  That's the point of requiring
>integration with maintainer scripts (via triggers or direct invocation).
>My understanding is that this is exactly what dh_installtmpfiles already
>does, via generating an explicit call to systemd-tmpfiles --create.

Hmm, that sounds okay-ish, except…

>Or am I missing something?

what you described of course does not work for /tmp and /run.
It is viable for /var/tmp etc.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1149533

Thorsten Glaser <t.glaser@tarent.de> writes:

> what you described of course does not work for /tmp and /run.
> It is viable for /var/tmp etc.

Well, it does work for /tmp and /run as well as anything else can possibly
work for /tmp and /run inside a chroot, namely if you're running anything
in a chroot that needs directories created in /tmp and /run, the chroot
either needs to have a persistent /tmp and /run or you have to arrange for
it to run at least some init scripts during boot.

My experience is that mostly the sorts of stuff that needs specific
directories in /tmp and /run isn't run in a chroot, and when it is, often
they just use persistent /tmp and /run.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149534

On Tue, 13 Jun 2023, Russ Allbery wrote:

>namely if you're running anything
>in a chroot that needs directories created in /tmp and /run, the chroot
>either needs to have a persistent /tmp and /run or you have to arrange for
>it to run at least some init scripts during boot.

I very much disagree here. Both /tmp and /run are volatile, and for /tmp
there usually even are cronjobs that delete old files, so programs that
need anything in there must create it themselves at startup (via wrapper
scripts if needed) if absent.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1149538

Thorsten Glaser <t.glaser@tarent.de> writes:
> On Tue, 13 Jun 2023, Russ Allbery wrote:

>> namely if you're running anything in a chroot that needs directories
>> created in /tmp and /run, the chroot either needs to have a persistent
>> /tmp and /run or you have to arrange for it to run at least some init
>> scripts during boot.

> I very much disagree here. Both /tmp and /run are volatile, and for /tmp
> there usually even are cronjobs that delete old files, so programs that
> need anything in there must create it themselves at startup (via wrapper
> scripts if needed) if absent.

Ah, I think I understand what you're getting at.  You're talking about
using the init script of a daemon as this sort of wrapper script for
running it in a chroot, by invoking the init script outside of an init
system as root, but inside the chroot.

This works in some situations when the init script has no other
dependencies, but is going to start bit-rotting because init scripts are
less frequently tested and people are going to forget to add separate code
to handle cases that are already handled by tmpfiles.d or the systemd
unit.  The replacement is to first run systemd-tmpfiles --create in the
chroot and then manually run the init script as before.  That does add an
additional step to the (somewhat rare) case of running daemons in chroots,
but it has the advantage of not having to add runtime code to every
package to create directories (often incorrectly, without handling edge
cases), and it's not that different from what you'd need to do to start
daemons in chroots that have dependencies on other daemons.  (It would
also be easy to add to a generic wrapper script for starting a daemon in a
Debian chroot that does this for you.)

If you're just talking about programs that need temporary directories in
/tmp (not /run, which is owned by root) owned by the same user that the
program is running as, or programs that only run as root creating PID
files in /run, then that is unrelated to this bug so far as I can tell;
nothing we're talking about here changes that behavior, because nothing
needs to be pre-created.

-- 
Russ Allbery (rra@debian.org)              <https://www.eyrie.org/~eagle/>

[toc] | [prev] | [next] | [standalone]

#1149563

On Tue, 13 Jun 2023, Russ Allbery wrote:

>Ah, I think I understand what you're getting at.  You're talking about
>using the init script of a daemon as this sort of wrapper script for

Not really. I was talking about normal programs, not dæmons.
I have the expectation that these, when invoked, create their
necessary temporary files/directories when they are placed on
volatile storage, i.e. /tmp and /run and possibly /var/tmp.

>nothing we're talking about here changes that behavior, because nothing
>needs to be pre-created.

Ah, good then.

For dæmons, running them in chroots is usually more tricky
anyway. Ideally, just /etc/init.d/foo {stop|start} would
work, but there’s situations where that doesn’t suffice.
If maintainers can get the former working, fine.

bye,
//mirabilos
-- 
Infrastrukturexperte • tarent solutions GmbH
Am Dickobskreuz 10, D-53121 Bonn • http://www.tarent.de/
Telephon +49 228 54881-393 • Fax: +49 228 54881-235
HRB AG Bonn 5168 • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

                        ****************************************************
/⁀\ The UTF-8 Ribbon
╲ ╱ Campaign against      Mit dem tarent-Newsletter nichts mehr verpassen:
 ╳  HTML eMail! Also,     https://www.tarent.de/newsletter
╱ ╲ header encryption!
                        ****************************************************

[toc] | [prev] | [next] | [standalone]

#1148788

On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 at 14:56, Simon McVittie <smcv@debian.org> wrote:
> > So I think the only realistic options for packages that hard-require
> > this functionality (not all do) are:
> >
> > 1. Depends: systemd | systemd-tmpfiles
> > 2. Depends: systemd-tmpfiles-standalone | systemd-tmpfiles
> > 3. Depends: default-systemd-tmpfiles | systemd-tmpfiles

In case it's not obvious, (2.) should say
systemd-standalone-tmpfiles | systemd-tmpfiles (and the same everywhere
else that I mentioned systemd-tmpfiles-standalone).

> Our time is worth more than 80K or whatever it is of disk space in a
> throw-away container.

I agree that the systemd maintainers' time is a limited resource that we
should not waste, but that size estimate is off by a couple of orders of
magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles and
-sysusers are about 700K of Uncompressed Size between them, while the
full systemd and libsystemd-shared packages add up to about 15M. For
genuinely throwaway containers, yes, it's not worth optimizing this,
but for containers that will be archived in a registry and/or kept
running longer-term, that seems like enough that maintainers of Docker
containers, etc. will want to use the standalone binaries if they are
sufficient for the container's needs.

(This is ignoring any extra library dependencies that might be required by
systemd and libsystemd-shared but unnecessary for the standalone binaries;
if there are any, then obviously the effective size delta increases.)

    smcv

[toc] | [prev] | [next] | [standalone]

#1148794

[Multipart message — attachments visible in raw view] — view raw

On Mon, 5 Jun 2023 10:11:46 +0100 Simon McVittie <smcv@debian.org>
wrote:
> On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> > Our time is worth more than 80K or whatever it is of disk space in
a
> > throw-away container.
> 
> I agree that the systemd maintainers' time is a limited resource that
we
> should not waste, but that size estimate is off by a couple of orders
of
> magnitude. On amd64, aptitude tells me systemd-standalone-tmpfiles
and
> -sysusers are about 700K of Uncompressed Size between them, while the
> full systemd and libsystemd-shared packages add up to about 15M. For
> genuinely throwaway containers, yes, it's not worth optimizing this,
> but for containers that will be archived in a registry and/or kept
> running longer-term, that seems like enough that maintainers of
Docker
> containers, etc. will want to use the standalone binaries if they are
> sufficient for the container's needs.
> 
> (This is ignoring any extra library dependencies that might be
required by
> systemd and libsystemd-shared but unnecessary for the standalone
binaries;
> if there are any, then obviously the effective size delta increases.)

Sure, but again, those special cases that really care about that
particular angle can simply adjust their dependencies accordingly,
there's nothing stopping them from doing so. It does not need to be the
default.

-- 
Kind regards,
Luca Boccassi

[toc] | [prev] | [next] | [standalone]

#1148799

On Sun, Jun 04, 2023 at 02:56:59PM +0100, Simon McVittie wrote:
> I think one way or another, if anyone is going to set a package-level
> dependency on systemd-tmpfiles, the first (preferred) dependency needs to
> be on either a concrete provider (systemd or systemd-tmpfiles-standalone
> in this case), or a default-systemd-tmpfiles virtual package
> that only has one provider per architecture (which is the way
> {default-,}dbus-{system,session}-bus are handled). Otherwise, you
> can get a non-deterministic choice of default implementation, which
> seems strictly worse than either depending on systemd or depending on
> systemd-tmpfiles-standalone - if you're unlucky, it can have all the
> disadvantages of either one of those.

Thank you for the elaborate writeup. There is little to add to what you
write except for one minor aspect.

>   - actual result: apt's heuristic might have difficulty realising that
>     it needs to do that

I think we should be able to guide apt here. I recently had to look into
Replaces and in that process I also had to re-read policy section 7.6.2.
It details the "other" use of Replaces to guide a package manager (e.g.
apt) for changing implementations of an interface - which is exactly
what we are talking about here. In essence, it says that we should do:

Provides: systemd-tmpfiles
Conflicts: systemd-tmpfiles
Replaces: systemd-tmpfiles

And systemd-standalone-tmpfiles does that. :) But systemd does not. :(
systemd misses out on Conflicts and Replaces. I guess (but have not
verified) that once these are added, apt would be happier to "upgrade"
systemd-standalone-tmpfiles to systemd when needed.

I've also experimented with a minimal chroot, installed the standalone
tools and the asked apt to install libbiometric0 (which happens to have
a dependency on systemd) and apt was quite happy with removing the
standalone variants. This is still missing the consumers of the provided
facilities though, so it might not be representative.

Is there any concrete evidence of apt having difficulties in a real
situation? Or maybe a constructed example demonstrating this? Thanks for
being cautious, but I'd also like to understand whether this is
hypothetical or real.

Helmut

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.bugs.dist

csiph-web