11:00:00 #startmeeting 11:00:00 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 Useful Commands: #action #agreed #help #info #idea #link #topic. 11:00:21 #topic Roll Call 11:00:25 Timo Röhling 11:00:27 Matthew Vernon 11:00:31 David Prévot 11:00:35 Stefano Rivera (who is also in a meeting in #debconf-team) 11:04:28 Craig Small 11:05:08 Helmut Grohne 11:05:49 Welcome everyone! I hope you had a nice summer time (if you are in the northern hemisphere) 11:07:21 #topic Bug #1141909 tech-ctte: dh_installtmpfiles-generated dependencies 11:07:42 This is currently the only open bug we have 11:08:25 tricky one, normally there are two or three clear options and its just a trade-off between those 11:08:53 there is one clear question with two options: should systemd-tmpfiles be essential? 11:09:19 it's not the only question, but it is a core one and it is strictly boolean 11:09:40 or should its interface be essential (but potentially provided by one of many implementations) 11:09:54 tumbleweed: I implied that to be the case 11:10:09 fair enough 11:11:54 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 I get not pulling a whole bunch of systemd stuff in, but then how should tmpfiles be handled? 11:12:49 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 I agree, making it essential would not be great 11:13:15 +1 11:13:32 (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 Please not so fast. There are good reasons to make it essential 11:14:12 What got us the bug was libselinux1. Had systemd-tmpfiles been essential, there would not have been a dependency loop. 11:14:39 Additionally, being essential means that systemd-tmpfiles could be used in purge scripts. There is benefit to doing so. 11:15:25 but just to make it clear: you are now talking about the tmpfiles interface and not about the systemd "reference implementation" 11:15:30 To me those are valid arguments in favor and I'd not discard the option that quickly. 11:15:47 I agree a thing that does all this is great, the problem is the specific implementation 11:15:48 roehling: yes. those are two aspects easily mixed up 11:16:09 seeS: imo, the implementation is fixable (after displacing the maintainer) 11:16:43 is systemd-tmpfiles guaranteed to work without a running systemd? (e.g. app container) 11:16:49 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 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 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 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 Given systemd adoption and existence of opentmpfiles, I'm inclined to say that the world has settled on the interface. 11:21:39 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 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 okay, so let's assume we make the tmpfiles API essential 11:25:26 Can we start the other way? See if there is a good solution without making it essential? 11:25:46 Consequences: systemd must be restructured such that libsystemd-shared becomes coinstallable in different versions to satisfy policy requirements about essential packages 11:26:28 Consequences: systemd cannot be a policy-compliant systemd-tmpfiles provider for any package in forky(!), unless those packages issue a dependency. 11:27:49 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 ok so helmut's consequences are if it IS essential 11:28:24 Emperor's message sort of threw me there 11:29:17 I suggest we finish this hypothetical first 11:29:58 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 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 systemd-standalone-tmpfiles does not suffer from the problem as it is statically linked 11:31:38 opentmpfiles neither as it is a shell script 11:32:33 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 scratch that, it is seedfiles now 11:33:37 seedfiles is a simple C program. likely to satisfy essential properties given upgrading its deps to Pre-Deps 11:35:35 any further thoughts on essential systemd-tmpfiles or shall we move to the other side? 11:36:06 what was the benefit? besides not having everything depend on it 11:36:08 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 and what seeS says 11:36:23 seeS: purge scripts can use tmpfiles to remove their files in a declarative way 11:36:47 ok that's nice.. but seems a lot just for that 11:37:14 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 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 e.g. libselinux1 became a recommends 11:39:10 okay, let's switch to the alternative: can we get (part of) the benefits without making tmpfiles essential? 11:39:44 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 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 would'nt a debhelper tool the dependency work? you have debian/package.tmpfiles so it does.. stuff 11:41:06 yes, but debhelper needs to specify the dependency in such a way that you don't get systemd in your container 11:41:23 some .tmpfiles are not essential to the package. 11:41:24 Yep, but its not the developer doing this usually 11:41:56 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 So it would need a default (probably not-depending?) and a way to specify that a dependency should be generated. 11:43:45 which would probably lead to a class of regular bugs when this was missed 11:44:37 that's my concern. it will be confusing for a lot of people 11:44:42 there is a choice: debhelper can make the dependency opt-in or opt-out 11:46:54 the opt-out variant may be less error prone. 11:47:22 opt-out = it won't put the dependencies in the packages control file? 11:47:54 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 ok, thats my preference 11:48:42 you make the .tmpfiles and those directories or files just appear 11:49:38 and you get extra dependencies to make this happen 11:50:04 What would you think about reordering it as "systemd-standalone-tmpfiles | systemd | systemd-tmpfiles"? 11:50:25 the last one is the virtual package. we're listing something that very few people (but chroots) would install first 11:51:15 and on systemd-systems they'll just get systemd, which is the majority 11:51:19 that sounds like the sensible order 11:51:43 yeah, apt would not switch the provider without a need. 11:52:29 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 It's annoying, but sounds like reasonably easy to solve 11:53:03 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 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 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 [sorry, I had assumed we'd run for an hour, so will have to vanish soon] 11:54:57 tumbleweed: pre-depends don't help with purge scripts. purge scripts can only assume essential. 11:55:05 helmut: ack 11:55:11 Emperor: I am aiming for an hour :) 11:56:13 any other remarks on this? do we agree on the consensus helmut outlined? 11:56:30 downside of non-essential tmpfiles: you cannot use systemd-tmpfiles in preinst scripts unless you pre-depend on systemd 11:57:01 (no package does that: https://binarycontrol.debian.net/?q=systemd-tmpfiles&path=preinst) 11:57:10 thanks for answering the question before I asked it :) 11:58:16 i agree on the consesus 11:58:37 even if i can't spell it 11:59:30 I assume that you, helmut, will continue driving the bug? 11:59:32 likewise (I'm not even going to try ;p ) 12:00:14 helmut: it seems we would have until forky's release to make a decison on systemd-tmpfiles being an essential interface 12:00:25 that could probably reasonably be done by the usual methods (debian-devel discussion) 12:00:28 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 #agreed systemd-tmpfiles should not become essential, debhelper should have an opt-out for tmpfiles deps 12:00:56 Any volunteers for the procedural part? 12:02:20 not me, I'm off on holiday in the not-too-distant future 12:02:24 taffit: do you feel up to the task? 12:03:11 mmmm’kay 12:03:22 thanks :) 12:03:29 #topic AOB 12:03:57 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 cu 12:04:51 No AOB for me 12:05:51 alright, then. Thanks everyone for your time 12:05:55 #endmeeting