Sean Whitton wrote:
> On Sun 17 Sep 2023 at 10:52am -07, Russ Allbery wrote:
> > So far as I can tell, the only important part is that the directory
> > be registered in tmpfiles.d (or a service unit) so that it can be
> > recreated when needed.
>
> Something which I don't think has been mentioned
On Sun, 17 Sept 2023 at 17:35, Luca Boccassi wrote:
>
> To do the tmpfiles purge/reset I have two WIP PRs, one against
> sd-tmpfiles, and one against debhelper. I need to pick them up again
> and finish that, and I am aiming to do so within the next couple of
> months.
Sorry for bumping the
Hello,
On Sun 17 Sep 2023 at 10:52am -07, Russ Allbery wrote:
> I don't see how shipping empty directories in a deb package affects this
> in any way. You're going to have to be considerably more specific about
> what invariant is being violated or what error you're expecting.
>
> One of the
On Sun, 17 Sept 2023 at 18:53, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > Let me clarify, here I meant something much simpler - the image
> > installed is a 'normal' one, with r/w root and managed by apt as usual
> > (ie: not immutable image-based) but with a repart.d snippet that
Le dim. 17 sept. 2023 à 21:26, Russ Allbery a écrit :
> Based on previous discussion with Guillem, I think the direction Guillem
> is headed is something like adding a new member (or field in another
> member) to the deb format that holds a list of volatile files that the
> package considers
Alexandre Detiste writes:
> The ugly magic behind the curtain:
> ls /usr/libexec/cruft/ -1
> LOGROTATE -> that parses these for path
> SERVICES -> added today reading this discussion, it reads
> CacheDirectory= & StateDirectory= from *.service
> TMPFILES -> that
Bill Allombert writes:
> As I said, filling the caches in /var/cache. For that they need to exist
> with correct ownership and permissions.
Sorry, I think I saw that and then edited my message more and lost it
again.
That use case makes sense to me, and without the directory already
present,
On Sun, Sep 17, 2023 at 08:28:56AM -0700, Russ Allbery wrote:
> Bill Allombert writes:
> > On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> >> On Sep 17, Russ Allbery wrote:
>
> >>> (I am a little confused by this wording, but I think what you're
> >>> saying is that /usr is
So there are 3 distinct interlinked goals:
- tmpfiles.d itself
- recovering from missing /var (+ later /etc)
- volatile file tracking
Just finishing the first step without going to far in either
other tracks would be so great already.
Le dim. 17 sept. 2023 à 19:57, Russ Allbery a écrit :
Luca Boccassi writes:
> Let me clarify, here I meant something much simpler - the image
> installed is a 'normal' one, with r/w root and managed by apt as usual
> (ie: not immutable image-based) but with a repart.d snippet that causes
> a new /var to be created on-the-fly on first boot if
On Sun, 17 Sept 2023 at 00:12, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > Aside from more practical considerations, shipping /var content in
> > packages is problematic because it's supposed to be local variable data,
> > that can be removed without breaking a system.
>
> Unless I'm
On Sep 17, Bill Allombert wrote:
> Does not that would break users expectation that the system image contains
> /var
> before the first boot ?
I am not aware of such expectations.
> A lot of things in /var are caches that are mostly instance-independent and
> can
> be prefilled, but for that,
Bill Allombert writes:
> On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
>> On Sep 17, Russ Allbery 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
On Sun, Sep 17, 2023 at 10:41:55AM +0200, Marco d'Itri wrote:
> On Sep 17, Russ Allbery 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
On Sep 17, Russ Allbery 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
> "Luca" == Luca Boccassi writes:
Luca> Aside from more practical considerations, shipping /var
Luca> content in packages is problematic because it's supposed to be
Luca> local variable data,
I agree with the above.
Luca> that can be removed without breaking a
Luca>
Le dim. 17 sept. 2023 à 01:15, Russ Allbery a écrit :
> Luca Boccassi writes:
>
> One would need to duplicate empty directories in /var (that don't have
> dynamic ownership). I'm dubious that's a significant burden (it's two or
> three lines in debian/rules), but if it is,
> one
Luca Boccassi writes:
> Aside from more practical considerations, shipping /var content in
> packages is problematic because it's supposed to be local variable data,
> that can be removed without breaking a system.
Unless I'm missing something, including the directory in the deb won't
make any
Simon McVittie writes:
> The key piece of information that was missing from your previous
> proposal was that systemd-tmpfiles interface versions match upstream
> systemd version numbers. As a concrete example, if someone wants to
> upload an implementation other than the one from systemd, it
On Fri, 15 Sept 2023 at 22:18, Russ Allbery wrote:
>
> Guillem Jover writes:
>
> > Not shipping these empty directories in the .deb seems like a regression
> > or a disservice to me. Even for things that might get deleted because
> > things like our policy or the FHS allows for it (say stuff
Guillem Jover writes:
> Not shipping these empty directories in the .deb seems like a regression
> or a disservice to me. Even for things that might get deleted because
> things like our policy or the FHS allows for it (say stuff under
> /var/cache), as «dpkg --verify» can be useful. Because of
Hi!
On Tue, 2023-09-12 at 22:17:44 -0700, Russ Allbery wrote:
> Russ Allbery writes:
> > Russ Allbery writes:
> >> Maybe the right way to do this is just have two examples, one as the
> >> default and another if you're using tmpfiles.d functionality added in a
> >> specific version of systemd
On Wed, 13 Sept 2023 at 15:37, Sam Hartman wrote:
>
> > "Russ" == Russ Allbery writes:
>
> I don't know if this needs seconds, but I reviewed all the text and it
> looks good.
> If seconds are required, I second.
Same, in case ownership passes to Russ, seconded/approved/you have my
> "Russ" == Russ Allbery writes:
I don't know if this needs seconds, but I reviewed all the text and it
looks good.
If seconds are required, I second.
signature.asc
Description: PGP signature
On Tue, 12 Sep 2023 at 22:17:44 -0700, Russ Allbery wrote:
> >> Maybe the right way to do this is just have two examples, one as the
> >> default and another if you're using tmpfiles.d functionality added in a
> >> specific version of systemd that's newer than the version shipped with
> >> the
Russ Allbery writes:
> Russ Allbery writes:
>> Maybe the right way to do this is just have two examples, one as the
>> default and another if you're using tmpfiles.d functionality added in a
>> specific version of systemd that's newer than the version shipped with
>> the stable version of
Russ Allbery writes:
> Maybe the right way to do this is just have two examples, one as the
> default and another if you're using tmpfiles.d functionality added in a
> specific version of systemd that's newer than the version shipped with
> the stable version of Debian prior to the one you're
On Mon, 11 Sep 2023, 17:58 Russ Allbery, wrote:
> Luca Boccassi writes:
>
> > Two more things went missing: Simon's suggestion on the versioned
> > dependencies on the virtual packages,
>
> Ah, yes, I'm sorry, I talked myself out of that and then completely forgot
> the previous discussion so
Luca Boccassi writes:
> Two more things went missing: Simon's suggestion on the versioned
> dependencies on the virtual packages,
Ah, yes, I'm sorry, I talked myself out of that and then completely forgot
the previous discussion so didn't say anything.
My concern is that it felt like we were
On Mon, 11 Sept 2023 at 07:01, Russ Allbery wrote:
>
> As usual, the things I notice only after I post text, even though I'd
> already read it several times.
>
> Russ Allbery writes:
>
> > +Volatile and temporary files (``tmpfiles.d``)
> > +-
> > +
> >
As usual, the things I notice only after I post text, even though I'd
already read it several times.
Russ Allbery writes:
> +Volatile and temporary files (``tmpfiles.d``)
> +-
> +
> +Some packages require empty directories, files with trivial content
Luca Boccassi writes:
> Moved as suggested. Also incorporated your suggestion on the versioned
> virtual package dependency verbatim.
Okay, I felt like doing editing this evening, apparently, so even though
only you, Sam, and Simon had a chance to respond, I went ahead and did the
editing. I'm
Please remove the following email address: e.little...@gmail.com
On Sat, Sep 9, 2023 at 10:54 PM Russ Allbery wrote:
> Luca Boccassi writes:
>
> > Sure, updated as suggested.
>
> I have a bunch of minor wording fixes that I'd want to make at this before
> merging, but that should be
> "Luca" == Luca Boccassi writes:
Luca> On Sun, 10 Sept 2023 at 11:31, Simon McVittie wrote:
>>
>> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
>> > Luca, am I right that service directories are specific to,
>> well, services? > If so, what would you
On Sun, 10 Sept 2023 at 11:31, Simon McVittie wrote:
>
> On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> > Luca, am I right that service directories are specific to, well, services?
> > If so, what would you think of moving them to Policy 9.3 alongside the
> > other discussion of
In general I support this direction.
On Sun, 25 Jun 2023 at 16:55:44 +0100, Luca Boccassi wrote:
> Packages shipping ``tmpfiles.d`` snippets should
> +depend on the appropriate virtual packages in the following order:
> +``default-systemd-tmpfiles | systemd-tmpfiles``.
I think it's worth saying
On Sat, 09 Sep 2023 at 19:51:50 -0700, Russ Allbery wrote:
> Luca, am I right that service directories are specific to, well, services?
> If so, what would you think of moving them to Policy 9.3 alongside the
> other discussion of systemd units? They feel out of place here, since
> packages that
Luca Boccassi writes:
> Sure, updated as suggested.
I have a bunch of minor wording fixes that I'd want to make at this before
merging, but that should be straightforward to do. Before I invest the
time in that, I want to check the opinions of everyone else following
along and see if the
On Sun, 23 Jul 2023 12:17:05 +0100 Luca Boccassi
wrote:
> On Tue, 20 Jun 2023 22:53:24 +0100 Luca Boccassi
> wrote:
> > On Sun, 18 Jun 2023 13:38:12 +0100 Luca Boccassi
> > wrote:
> > > On Sun, 18 Jun 2023 at 13:03, Sean Whitton
>
> > wrote:
> > > >
> > > > Hello,
> > > >
> > > > On Fri 16 Jun
On Tue, 20 Jun 2023 22:53:24 +0100 Luca Boccassi
wrote:
> On Sun, 18 Jun 2023 13:38:12 +0100 Luca Boccassi
> wrote:
> > On Sun, 18 Jun 2023 at 13:03, Sean Whitton
> wrote:
> > >
> > > Hello,
> > >
> > > On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote:
> > >
> > > > Is there anything
Some grammer thoughts. Especially i suggest avoiding the word
'integrate' wherever possible
Luca Boccassi writes:
> +Service Directories
> +
> +Init systems other than ``systemd`` should allow providing the same
"allow providing" should be "provide" (or "support"? or "allow [who] to
[do
On Sun, 25 Jun 2023 at 16:52, Ansgar wrote:
>
> Hi Luca,
>
> On Tue, 2023-06-20 at 22:53 +0100, Luca Boccassi wrote:
> > Russ, anything I've missed that you want me to change from the most
> > recent revision at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#160 ?
>
> I suggest a
Hi Luca,
On Tue, 2023-06-20 at 22:53 +0100, Luca Boccassi wrote:
> Russ, anything I've missed that you want me to change from the most
> recent revision at
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945269#160 ?
I suggest a minor change:
In the paragraph
+---
| Init systems other than
On Sun, 18 Jun 2023 13:38:12 +0100 Luca Boccassi
wrote:
> On Sun, 18 Jun 2023 at 13:03, Sean Whitton
wrote:
> >
> > Hello,
> >
> > On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote:
> >
> > > Is there anything needed from me to make progress on this? Any
changes
> > > required to the last
On Sun, 18 Jun 2023 at 13:03, Sean Whitton wrote:
>
> Hello,
>
> On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote:
>
> > Is there anything needed from me to make progress on this? Any changes
> > required to the last revision posted?
>
> Yes, Russ posted some comments on your most recent
Hello,
On Fri 16 Jun 2023 at 05:57PM +01, Luca Boccassi wrote:
> Is there anything needed from me to make progress on this? Any changes
> required to the last revision posted?
Yes, Russ posted some comments on your most recent revision, I believe.
--
Sean Whitton
signature.asc
Description:
On Fri, 16 Jun 2023 10:51:17 +0100 Sean Whitton
wrote:
> Hello,
>
> On Tue 13 Jun 2023 at 05:58PM +01, Mark Hindley wrote:
>
> > There is a new upstream version of elogind[1] that is already
packaged in
> > Devuan[2] although that uncovered up an upstream issue that I am
waiting to be
> >
Hello,
On Tue 13 Jun 2023 at 05:58PM +01, Mark Hindley wrote:
> There is a new upstream version of elogind[1] that is already packaged in
> Devuan[2] although that uncovered up an upstream issue that I am waiting to be
> resolved[3]. So, maybe by the end of this month?
>
> However, that is only
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,
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
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
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
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
>
On Wed, 7 Jun 2023 at 11:46, Luca Boccassi wrote:
>
> On Wed, 7 Jun 2023 at 11:29, Simon McVittie wrote:
> >
> > On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> > > Luca Boccassi writes:
> > > > +Packages might need additional files or directories to implement their
> > > >
On Wed, 7 Jun 2023 at 11:29, Simon McVittie wrote:
>
> On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> > Luca Boccassi writes:
> > > +Packages might need additional files or directories to implement their
> > > +functionality. Directories that are located under ``/var/`` or
> > >
On Wed, 7 Jun 2023 at 04:40, Russ Allbery wrote:
>
> Luca Boccassi writes:
>
> > diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> > index b34c183..30ce013 100644
> > --- a/policy/ch-files.rst
> > +++ b/policy/ch-files.rst
> > @@ -722,6 +722,43 @@ The name of the files and directories
On Tue, 06 Jun 2023 at 20:40:52 -0700, Russ Allbery wrote:
> Luca Boccassi writes:
> > +Packages might need additional files or directories to implement their
> > +functionality. Directories that are located under ``/var/`` or
> > +``/etc/``, and files that are located under ``/var/``, must not
Luca Boccassi writes:
> diff --git a/policy/ch-files.rst b/policy/ch-files.rst
> index b34c183..30ce013 100644
> --- a/policy/ch-files.rst
> +++ b/policy/ch-files.rst
> @@ -722,6 +722,43 @@ The name of the files and directories installed by
> binary packages
> outside the system PATH must be
On Tue, 06 Jun 2023 13:07:37 +0100 Luca Boccassi
wrote:
> Sounds like a good plan to me.
Updated as suggested.
--
Kind regards,
Luca Boccassi
From 20a655663c17914699e72e48a74daca03fd42a22 Mon Sep 17 00:00:00 2001
From: Luca Boccassi
Date: Tue, 9 May 2023 01:38:13 +0100
Subject: [PATCH] Define
On Tue, 6 Jun 2023 11:58:07 +0100 Simon McVittie
wrote:
> On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> > On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > > Another possible mitigation which I haven't previously seen
proposed
> > > is giving *elogind* a Depends or
On Tue, 06 Jun 2023 at 11:37:51 +0100, Sean Whitton wrote:
> On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie wrote:
> > 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
Hello,
On Sun 04 Jun 2023 at 02:56PM +01, Simon McVittie 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:
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
On Mon, 5 Jun 2023 09:53:39 +0100 Simon McVittie
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
On Mon, 5 Jun 2023 10:11:46 +0100 Simon McVittie
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
>
On Mon, 05 Jun 2023 at 01:36:25 +0100, Luca Boccassi wrote:
> On Sun, 4 Jun 2023 at 14:56, Simon McVittie 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:
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
On Sun, 4 Jun 2023 at 14:56, Simon McVittie 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 wrote:
> > > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi
(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 wrote:
> > On Tue 09 May 2023 at 01:44AM +01, Luca Boccassi wrote:
> > > For now I've kept only a mention of the
On Sun, 4 Jun 2023 at 12:02, Sean Whitton 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:
> >
> >
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
On Sun, 18 Sep 2022 20:52:23 -0700 Russ Allbery wrote:
> Ansgar writes:
>
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
>
> > It could also be used to create trivial files
Ansgar writes:
> I would like to recommend packages to use tmpfiles.d(5) to manage
> creating directories in locations such as /var or /etc instead of
> maintainer scripts.
> It could also be used to create trivial files below /var that should be
> recreated if deleted by accident (such as
On Sat, 30 Nov 2019 at 10:58:23 -0800, Russ Allbery wrote:
> Guillem Jover writes:
> > I don't mind much how this could end up being hooked into various init
> > systems and chroot/container managers. I can see how it could be done by
> > the respective imeplementations themselves or provided by
Guillem Jover writes:
> The way I see it, any pathname "owned" by a package is within the realm
> of dpkg, which is in charge of tracking and managing the filesystem
> contents for system software. I've, for example, always found it a big
> defficiency that when querying dpkg about system
Hi!
On Fri, 2019-11-29 at 09:13:47 -0800, Russ Allbery wrote:
> Guillem Jover writes:
> > As I mentioned on debian-devel, I think major parts of this and of the
> > sysuser stuff fall under dpkg realm. And my plan is to implement this
> > kind of functionality natively in dpkg, regardless of
Guillem Jover writes:
> As I mentioned on debian-devel, I think major parts of this and of the
> sysuser stuff fall under dpkg realm. And my plan is to implement this
> kind of functionality natively in dpkg, regardless of whatever the
> outcome of that GR is.
> Of course some parts of the
On Fri, 2019-11-22 at 10:12:06 -0800, Russ Allbery wrote:
> Ansgar writes:
> > I think no option says we shouldn't use services that don't rely on
> > systemd as pid-1 (which also includes widely used things like udev).
>
> I agree, but if, say, Sam's option 3 wins, we can directly incorporate
>
Ansgar writes:
> I think no option says we shouldn't use services that don't rely on
> systemd as pid-1 (which also includes widely used things like udev).
I agree, but if, say, Sam's option 3 wins, we can directly incorporate
this, whereas if, say, Ian's option wins, then we should have a
On Fri, 2019-11-22 at 09:05 -0800, Russ Allbery wrote:
> Simon McVittie writes:
> > I had also thought that, in the current state of non-systemd-init-world,
> > having a dependency on a package containing systemd-tmpfiles was likely
> > to be practically problematic because it would indirectly
Simon McVittie writes:
> On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote:
>> I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1
> It doesn't, but its dh_installsystemd integration currently does, so
> maintainer scripts relying on it would currently be buggy. I think it
On Fri, 22 Nov 2019 at 14:05:50 +0100, Ansgar wrote:
> I'm fairly sure that systemd-tmpfiles doesn't require systemd as pid-1
It doesn't, but its dh_installsystemd integration currently does, so
maintainer scripts relying on it would currently be buggy. I think it
would be premature to recommend
On Fri, 2019-11-22 at 12:07 +, Simon McVittie wrote:
> On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote:
> > I would like to recommend packages to use tmpfiles.d(5) to manage
> > creating directories in locations such as /var or /etc instead of
> > maintainer scripts.
>
> Using
On Fri, 22 Nov 2019 at 09:03:29 +0100, Ansgar wrote:
> I would like to recommend packages to use tmpfiles.d(5) to manage
> creating directories in locations such as /var or /etc instead of
> maintainer scripts.
Using tmpfiles.d(5) seems like a good thing to encourage, but using
them *instead of*
Package: debian-policy
I would like to recommend packages to use tmpfiles.d(5) to manage
creating directories in locations such as /var or /etc instead of
maintainer scripts.
It could also be used to create trivial files below /var that should be
recreated if deleted by accident (such as atd's
100 matches
Mail list logo
