11:00:00 <roehling> #startmeeting
11:00:00 <MeetBot> Meeting started Thu Sep 10 11:00:00 2026 UTC.  The chair is roehling. Information about MeetBot at https://wiki.debian.org/MeetBot.
11:00:00 <MeetBot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:00:21 <roehling> #topic Roll Call
11:00:25 <roehling> Timo Röhling
11:00:27 <Emperor> Matthew Vernon
11:00:31 <taffit> David Prévot
11:00:35 <tumbleweed> Stefano Rivera (who is also in a meeting in #debconf-team)
11:04:28 <seeS> Craig Small
11:05:08 <helmut> Helmut Grohne
11:05:49 <roehling> Welcome everyone! I hope you had a nice summer time (if you are in the northern hemisphere)
11:07:21 <roehling> #topic Bug #1141909 tech-ctte: dh_installtmpfiles-generated dependencies
11:07:42 <roehling> This is currently the only open bug we have
11:08:25 <seeS> tricky one, normally there are two or three clear options and its just a trade-off between those
11:08:53 <helmut> there is one clear question with two options: should systemd-tmpfiles be essential?
11:09:19 <helmut> it's not the only question, but it is a core one and it is strictly boolean
11:09:40 <tumbleweed> or should its interface be essential (but potentially provided by one of many implementations)
11:09:54 <helmut> tumbleweed: I implied that to be the case
11:10:09 <tumbleweed> fair enough
11:11:54 <helmut> As context, let me point to #1109564. A side quest of that report is that systemd-tmpfiles does not work at all times.
11:12:14 * Emperor not inclined currently to think that system-tmpfiles should become essential
11:12:20 <seeS> I get not pulling a whole bunch of systemd stuff in, but then how should tmpfiles be handled?
11:12:49 <helmut> My own opinion is that the systemd binary package as a systemd-tmpfiles provider does not currently provide the semantics required by Debian policy about essential packages ("must work at all times even when unpacked").
11:13:09 <seeS> I agree, making it essential would not be great
11:13:15 <roehling> +1
11:13:32 <Emperor> (I'm not sure why the suggestion from years back of having some options to dh to specify whether the tempfiles fragments in maintscripts should be guarded and/or a dependency declared never went anywhere)
11:13:40 <helmut> Please not so fast. There are good reasons to make it essential
11:14:12 <helmut> What got us the bug was libselinux1. Had systemd-tmpfiles been essential, there would not have been a dependency loop.
11:14:39 <helmut> Additionally, being essential means that systemd-tmpfiles could be used in purge scripts. There is benefit to doing so.
11:15:25 <roehling> but just to make it clear: you are now talking about the tmpfiles interface and not about the systemd "reference implementation"
11:15:30 <helmut> To me those are valid arguments in favor and I'd not discard the option that quickly.
11:15:47 <seeS> I agree a thing that does all this is great, the problem is the specific implementation
11:15:48 <helmut> roehling: yes. those are two aspects easily mixed up
11:16:09 <helmut> seeS: imo, the implementation is fixable (after displacing the maintainer)
11:16:43 <tumbleweed> is systemd-tmpfiles guaranteed to work without a running systemd? (e.g. app container)
11:16:49 <roehling> do we consider the tmpfiles interface mature enough and ubiquitous enough that we want to commit to supporting it in the essential set?
11:17:29 <helmut> tumbleweed: the answer should be answered in the context of each provider. the short answer (according to my understanding) is that each of them can be made to work in such a way.
11:18:59 <helmut> though note that systemd-tmpfiles is actually several contracts (which again complexifies things): A. /usr/bin/systemd-tmpfiles as a tool to run against tmpfiles.d snippets vs B. tmpfiles.service as a boottime service running before service units to apply tmpfiles.d snippets
11:19:16 <seeS> Looking at one of my packages, the clean way of handing the directories is great but the Depends: line is not so great
11:21:11 <helmut> Given systemd adoption and existence of opentmpfiles, I'm inclined to say that the world has settled on the interface.
11:21:39 <Emperor> Policy is quite cautious on adding things to the essential set ( https://www.debian.org/doc/debian-policy/ch-binary.html#essential-packages )
11:22:42 <helmut> How about we split the meeting (into two chronolgical sections) one assuming systemd-tmpfiles (the /usr/bin/ API) becomes essential and the other assuming it does not.
11:25:06 <roehling> okay, so let's assume we make the tmpfiles API essential
11:25:26 <Emperor> Can we start the other way? See if there is a good solution without making it essential?
11:25:46 <helmut> Consequences: systemd must be restructured such that libsystemd-shared becomes coinstallable in different versions to satisfy policy requirements about essential packages
11:26:28 <helmut> Consequences: systemd cannot be a policy-compliant systemd-tmpfiles provider for any package in forky(!), unless those packages issue a dependency.
11:27:49 <helmut> Consequences: some package (e.g. base-files) must depend on systemd-tmpfiles (with some default alternative) to allow switching providers (like awk)
11:28:12 <seeS> ok so helmut's consequences are if it IS essential
11:28:24 <seeS> Emperor's message sort of threw me there
11:29:17 <roehling> I suggest we finish this hypothetical first
11:29:58 <roehling> What would we gain in benefits to justify the non-trivial changes we would need to make (and potentially fight with systemd upstream about)
11:30:45 <helmut> I don't think there is a fight with systemd upstream. The change to the systemd package is making libsystemd-shared coinstallable, which basically means that it goes through NEW on every upload.
11:31:28 <helmut> systemd-standalone-tmpfiles does not suffer from the problem as it is statically linked
11:31:38 <helmut> opentmpfiles neither as it is a shell script
11:32:33 <tumbleweed> so... we describe the current issue as a bug, given that we have determined systemd-tmpfiles needs to behave as an essential package
11:32:46 <helmut> scratch that, it is seedfiles now
11:33:37 <helmut> seedfiles is a simple C program. likely to satisfy essential properties given upgrading its deps to Pre-Deps
11:35:35 <helmut> any further thoughts on essential systemd-tmpfiles or shall we move to the other side?
11:36:06 <seeS> what was the benefit? besides not having everything depend on it
11:36:08 <roehling> one question: is this a containable change or do we run the risk that future redesigns of systemd force us to make more/all of systemd essential?
11:36:19 <roehling> and what seeS says
11:36:23 <helmut> seeS: purge scripts can use tmpfiles to remove their files in a declarative way
11:36:47 <seeS> ok that's nice.. but seems a lot just for that
11:37:14 <helmut> another benefit is that we can use tmpfiles in all sorts of packages. at present, we cannot use it in any package that systemd depends on as that would create a loop
11:38:21 <helmut> though note that systemd massively reduced its own dependencies preferring dlopen(), so the set of packages that cannot use tmpfiles kept shrinking
11:38:45 <helmut> e.g. libselinux1 became a recommends
11:39:10 <roehling> okay, let's switch to the alternative: can we get (part of) the benefits without making tmpfiles essential?
11:39:44 <helmut> not making it essential means that each binary package needs to decide whether it requires tmpfiles.d to work (what Emperor said earlier)
11:40:19 <helmut> it also means that we need to figure out how to depend on it. "systemd | systemd-standalone-tmpfiles | systemd-tmpfiles" pulled systemd into chroots, and we likely do not want that
11:40:43 <seeS> would'nt a debhelper tool the dependency work? you have debian/package.tmpfiles so it does.. stuff
11:41:06 <Emperor> yes, but debhelper needs to specify the dependency in such a way that you don't get systemd in your container
11:41:23 <helmut> some .tmpfiles are not essential to the package.
11:41:24 <seeS> Yep, but its not the developer doing this usually
11:41:56 <helmut> debhelper cannot tell by itsefl whether your .tmpfiles is necessary for the operation of the package or a useful optional thing to have
11:43:14 <Emperor> So it would need a default (probably not-depending?) and a way to specify that a dependency should be generated.
11:43:45 <tumbleweed> which would probably lead to a class of regular bugs when this was missed
11:44:37 <seeS> that's my concern. it will be confusing for a lot of people
11:44:42 <helmut> there is a choice: debhelper can make the dependency opt-in or opt-out
11:46:54 <helmut> the opt-out variant may be less error prone.
11:47:22 <seeS> opt-out = it won't put the dependencies in the packages control file?
11:47:54 <helmut> opt-out = debhelper will add the dependency when it sees a tmpfiles.d config unless you explicitily tell it not to add the dependency
11:48:08 <seeS> ok, thats my preference
11:48:42 <seeS> you make the .tmpfiles and those directories or files just appear
11:49:38 <tumbleweed> and you get extra dependencies to make this happen
11:50:04 <helmut> What would you think about reordering it as "systemd-standalone-tmpfiles | systemd | systemd-tmpfiles"?
11:50:25 <helmut> the last one is the virtual package. we're listing something that very few people (but chroots) would install first
11:51:15 <Emperor> and on systemd-systems they'll just get systemd, which is the majority
11:51:19 <tumbleweed> that sounds like the sensible order
11:51:43 <helmut> yeah, apt would not switch the provider without a need.
11:52:29 <helmut> using systemd-tmpfiles in purge scripts would become annoying. likely, we'd need some debhelper-internal parser of tmpfiles that would create purge scripts from them
11:52:57 <roehling> It's annoying, but sounds like reasonably easy to solve
11:53:03 <seeS> I agree with this approach. if you have systemd already installed its all good and if not the non-systemd gets pulled in
11:53:48 <tumbleweed> helmut: this is because we're using Depends rather than Pre-Depends and the systemd implementation doesn't behave well during systemd upgrades
11:54:24 <helmut> My sentiment is that we have rough consensus on: 1. systemd-tmpfiles (the functionality) should not become essential. 2. debhelper should by default issue a dependency on systemd-tmpfiles when it is used. 3. the systemd-tmpfiles dependency hould order systemd-standalone-tmpfiles first despite it not being the default
11:54:38 <Emperor> [sorry, I had assumed we'd run for an hour, so will have to vanish soon]
11:54:57 <helmut> tumbleweed: pre-depends don't help with purge scripts. purge scripts can only assume essential.
11:55:05 <tumbleweed> helmut: ack
11:55:11 <roehling> Emperor: I am aiming for an hour :)
11:56:13 <roehling> any other remarks on this? do we agree on the consensus helmut outlined?
11:56:30 <helmut> downside of non-essential tmpfiles: you cannot use systemd-tmpfiles in preinst scripts unless you pre-depend on systemd
11:57:01 <helmut> (no package does that: https://binarycontrol.debian.net/?q=systemd-tmpfiles&path=preinst)
11:57:10 <tumbleweed> thanks for answering the question before I asked it :)
11:58:16 <seeS> i agree on the consesus
11:58:37 <seeS> even if i can't spell it
11:59:30 <roehling> I assume that you, helmut, will continue driving the bug?
11:59:32 <Emperor> likewise (I'm not even going to try ;p )
12:00:14 <tumbleweed> helmut: it seems we would have until forky's release to make a decison on systemd-tmpfiles being an essential interface
12:00:25 <tumbleweed> that could probably reasonably be done by the usual methods (debian-devel discussion)
12:00:28 <helmut> roehling: I actually prefer not to. I did a bit of the technical analysis, but I think it should receive more member involvement and splitting technical vs procedural things also is a good idea
12:00:41 <roehling> #agreed systemd-tmpfiles should not become essential, debhelper should have an opt-out for tmpfiles deps
12:00:56 <roehling> Any volunteers for the procedural part?
12:02:20 <Emperor> not me, I'm off on holiday in the not-too-distant future
12:02:24 <roehling> taffit: do you feel up to the task?
12:03:11 <taffit> mmmm’kay
12:03:22 <roehling> thanks :)
12:03:29 <roehling> #topic AOB
12:03:57 <roehling> If there's anything else, just give a quick shoutout, and we can schedule a new meeting as required
12:04:19 * Emperor got to vanish now, sorry. Bye all!
12:04:28 <roehling> cu
12:04:51 <seeS> No AOB for me
12:05:51 <roehling> alright, then. Thanks everyone for your time
12:05:55 <roehling> #endmeeting