On Tue, 13 Jun 2023 at 22:59, Luca Boccassi wrote:
>
> On Tue, 13 Jun 2023 at 22:49, Russ Allbery wrote:
> >
> > Luca Boccassi writes:
> >
> > > That essentially means it's fine to use diversions and ship releases
> > > using them, so that's exactly what will happen as per Murphy's law.
> >
> >
On Tue, 13 Jun 2023 at 22:49, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > That essentially means it's fine to use diversions and ship releases
> > using them, so that's exactly what will happen as per Murphy's law.
>
> I think we're reaching a consensus that "must" is appropriate for the
Luca Boccassi writes:
> That essentially means it's fine to use diversions and ship releases
> using them, so that's exactly what will happen as per Murphy's law.
I think we're reaching a consensus that "must" is appropriate for the
systemd configuration files, so this discussion is about how
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,
Hello,
On Tue 13 Jun 2023 at 08:45PM +01, Luca Boccassi wrote:
> That essentially means it's fine to use diversions and ship releases
> using them, so that's exactly what will happen as per Murphy's law.
> [...]
I don't believe you've made any new arguments in the message to which
I'm replying.
On Tue, 2023-06-13 at 12:51 -0700, Russ Allbery wrote:
> I still am curious if it's safe to configure the same files in both
> tmpfiles.d and in the unit file, because it would make it much easier for
> those who want to support other init systems to do so.
Having this configured in two places
On Tue, 13 Jun 2023 at 20:51, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > That paragraph is in the context of StateDirectory= and
> > RuntimeDirectory=. These are unit files options, so it's up to
> > alternative init systems to provide alternative and integrate them in
> > the
On Tue, 13 Jun 2023 08:39:24 -0700 Russ Allbery wrote:
> Sean Whitton writes:
>
> > I still find myself feeling queasy about adding this must-with-
caveat.
> > It feels like with the caveat you're trying to get something
between
> > "must" and "should", but then rather than build down from
Luca Boccassi writes:
> That paragraph is in the context of StateDirectory= and
> RuntimeDirectory=. These are unit files options, so it's up to
> alternative init systems to provide alternative and integrate them in
> the (eventual) init script, just as they are defined in the systemd
> unit.
On Tue, 13 Jun 2023 10:55:38 -0700 Russ Allbery wrote:
> > Init systems other than ``systemd`` should allow providing the same
> > functionality as appropriate for each system, for example managing the
> > directories from the init script shipped by the package.
>
> This sort of
Thorsten Glaser 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
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
Thorsten Glaser 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
On Tue, 13 Jun 2023, Russ Allbery wrote:
>Thorsten Glaser 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
Ansgar writes:
> On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
>> On Jun 13, Bill Allombert 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
Mark Hindley writes:
> I remain much less convinced that there is a consensus for requiring
> packages to use tmpfiles.d(5) for /var, /tmp and maybe /etc.
Well, for /tmp, /var/tmp, and /run, I think this is the right approach,
unless there is some other systemd unit configuration that is even
On Tue, 2023-06-13 at 18:36 +0200, Marco d'Itri wrote:
> On Jun 13, Bill Allombert 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
Sean,
On Tue, Jun 13, 2023 at 05:15:15PM +0100, Sean Whitton wrote:
> > In principle and just looking at the dependencies this seems a viable
> > solution. It is very similar to the way we handle the logind and
> > default-logind virtual packages.
>
> Thank you for reviewing. Do you have a
On Jun 13, Bill Allombert 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
signature.asc
Description: PGP
Thorsten Glaser 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
Hello Mark,
On Tue 13 Jun 2023 at 01:51PM +01, Mark Hindley wrote:
> On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote:
>> Exactly. My hope is that if we had:
>>
>> Package: systemd
>> Architecture: linux-any
>> Provides: default-systemd-tmpfiles, systemd-tmpfiles
>>
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
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
Sean Whitton writes:
> I still find myself feeling queasy about adding this must-with-caveat.
> It feels like with the caveat you're trying to get something between
> "must" and "should", but then rather than build down from "must", why
> not build up from "should"? I would like to propose:
>
Hello,
On Tue 06 Jun 2023 at 12:16PM +01, Luca Boccassi wrote:
> My understanding is that "should" is effectively optional, ie: it is
> not enough to make a package rc-buggy, and while they are generally
> followed, there is no actual hard requirement to do so. That is not
> enough for me and
Somehow I added Manjaro to my laptop, and it has a really nice GRUB boot
that upon reboot, it stays at the last choice. It's nice when a
particular partition is upgrading and rebooting, you don't need to be
present to redirect the reboot to the correct partition! This may not
be the right
Hello,
On Tue 06 Jun 2023 at 07:56PM -07, Russ Allbery wrote:
> Sean Whitton writes:
>
>> I think what's a bit peculiar here is using "must" for a case where
>> there might be package-specific exceptions. In other cases, Policy uses
>> "should" for these cases. Typically "must" rules are
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
Hello,
> diff --git a/policy/ch-binary.rst b/policy/ch-binary.rst
> index e517f26..4ceec3f 100644
> --- a/policy/ch-binary.rst
> +++ b/policy/ch-binary.rst
> +
> +Alternatives must never be used for ``systemd`` configuration files.
"Must not" rather than "must never" is our standard phrasing,
Simon,
Thanks for your care and insight with this and apologies for the delay in
replying (mails to elog...@packages.debian.org have been held up on a
mailserver).
On Tue, Jun 06, 2023 at 11:58:07AM +0100, Simon McVittie wrote:
> Exactly. My hope is that if we had:
>
> Package: systemd
>
30 matches
Mail list logo
