Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Michael Biebl: Hello Niels, hello Sebastian Hi Michael, Am 24.03.23 um 16:28 schrieb Niels Thykier: Sebastian Ramacher: [...] Any progress here? If this issue should be fixed for bookworm, time is running short. Cheers I find that anytime I look at this bug my motivation to work on Debian instantly vanishes. In fact, I cannot even motivate myself to read the bug log to figure out what the consensus is. Accordingly, I will play the constitution 2.1.1 and step out of the way. My attempt to raise this issue with debhelper and the release-team was to gather a consensus with how to deal with the affected packages. A change to debhelper seemed liked the most straightforward approach to me. I agree with all of this and I think you were both entitled and correct in raising the issue. I am still open to this being a bug in debhelper. It was not meant as an attempt to force Niels into something he feels uncomfortable with, which he obviously does. I apologize to Niels for that and hereby close this bug report. Michael Your reaction here does not match what I had expected from my email and I suspect my intentions were not perceived by you as I intended them. To start with the most important points: You have done *nothing* to me that requires an apology from you. You have *not* forced me to do something I am uncomfortable with. As far as I am concerned, there was and is *no* conflict between you and I. We are good if you ask me. I am mostly sad that I made you think otherwise, but that is on me. Coming back to what I wanted to communicate: Starting with the context, the timing of my email came after two mails asking for an update on this bug that had not been answered by anyone. I.e., my email was a response to the requests for a update on the bug - both requests were in my view reasonable. As the named maintainer/uploader of debhelper, there is always an implicit assumption that I will be proactive in dealing with bugs, when there is no clear owner of the bug. Especially bugs that affect the upcoming release during the freeze. Given that I did not see a response and I could not easily identify a clear owner of the bug, I felt these emails hanged on me via the implicit assumption. I wanted to make it very clear that I would *not* be able to live up to that assumption. If someone wanted this change, they would have to do it without involving me at any point. I was hoping that someone would take end to end ownership and deliver it without involving me. As opposed to a PR/patch that I would have to review - or leaving me to discuss with the RT what kind of change was acceptable this stage - or leaving me to reopen the discussion with the tech-ctte whether allowing services in /usr is acceptable as it would open up for file moves between /lib and /usr/lib, which they said they would not want when the original bug was filed (#995569). I would not have been able to do that and I doubt I will be able to do that any time soon. But if someone wanted to do that. Great! It would have been a burden off my shoulder. On the flip-side, if no one else was willing to do the work, then I would not have to feel bad about not being able to do it either. Either way would relieve me of the pressure of this bug. Eventually, dh_installsystemd (et al.) will probably have to support /usr/lib. If someone fixes that now, great. If someone fixes later, great. I do not mind the change. I mind the assumption that I will be doing it (in this or in future releases). Feel free to reopen this bug. As long as we all agree that for the timing being, *I* will *not* be interacting with the bug, do any design or review of the solution, or deal with any fallout of implementing the solution. Whoever owns up to dealing with all of that gets to deliver this feature. They get to do it without having to follow the NMU rules as far as I am concerned unless a co-maintainer steps up and takes ownership of this bug, because to me that is part of "stepping out of the way" when you are not volunteering to do the work. In summary: * I do not feel you did anything wrong or owe me an apology. * I mind doing the work; not the change. If you (anyone) want this change and you commit to doing it. Please reopen the bug and go ahead as long as you do not "depend" on or "need" me for any part of it. I hope my intentions were more clear this time. Best regards, Niels
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
FTR, I opened RC bugs against all the impacted packages so they will hopefully be fixed for bookworm See: https://udd.debian.org/cgi-bin/bts-usertags.cgi?user=debhelper%40packages.debian.org=systemd-files-in-usr-bookworm
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Sebastian Ramacher: [...] Any progress here? If this issue should be fixed for bookworm, time is running short. Cheers I find that anytime I look at this bug my motivation to work on Debian instantly vanishes. In fact, I cannot even motivate myself to read the bug log to figure out what the consensus is. Accordingly, I will play the constitution 2.1.1 and step out of the way. If there are any recent debhelper contributors that want to claim this, then I will give preference to them and how they want to handle it. Otherwise, if no debhelper contributor steps up, then I will waive the NMU process on this side of the release on the debhelper package to anyone, who ones to pick this up. Please keep the following in mind: 1) Be adviced that you need to look at multiple helpers that interact with the systemd services. Notably, dh_installsystemd, dh_installsystemduser and dh_installinit - all of which assumes there is one and only one directly for these services. Good luck 2) I would that you push the changes to the salsa repo (it is DD-writable by default, others will have to do a PR) but a nmudiff CC'ed to this bug on top of the main branch in salsa will do. - Please use the main branch, there are some translation changes since last upload, which should be a non-issue. - If you are a DD, just push the changes to main and move on. Do not expect me to review a PR before you upload. 3) I expect that you upload and handle any fall out. Fall out here includes judging consensus, fix FTBFS, RC bugs or deal with discussions including the tech-ctte or the release team about the proposed solution, managing the unblock request (etc.). - Assume I will not be involved in any of these steps. 3) If you do change any translatable strings, please consider to notify the translators. At least pt and de translators recently updated and I feel it would be a shame if they were not 100%. But not enough that I expect I will invest in a follow up upload. My apologies to the release team. Having been on the release team, I know this is probably not the message you wanted this close to the release. Sadly, it is the "best" I can do. With that said and done, as far as bug is concerned, I am out! Best regards, Niels
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-28 16:14:42 -0700, Sam Hartman wrote: > > "Michael" == Michael Biebl writes: > > Michael> If a service is not supposed to be enabled, then an > Michael> override for dh_installsystemd is the correct solution, > Michael> setting --no-enable, but not by moving it into a > Michael> subpackage. > > Sorry, I was imprecise. > Imagine something like a webserver. > You might well want to install the web server binary so you can run it > as a user for development testing an app or for sharing files. > But you might also want to install it as a system service. > I think two options are viable depending on factors like whether some > dependencies want to know that it is running as a system service and > how common each configuration will be: > > * Install a disabled unit by default but keep everything into one > package > > * or move the system service unit into its own package. If you just > want the binary you install one package, but if you want the system > service, you install the package containing the unit. > In this case the unit is enabled by default. > > If we were to move units back from /usr/lib/systemd/system to > /lib/systemd/system, the second case would potentially trigger the dpkg > bug. But: > > > Michael> I also don't see a good reason, why a unit file, once > Michael> installed in /usr/lib/systemd/system should ever move back > Michael> to /lib/systemd/system. > > I agree with you here. This requires keeping the debhelper change > rather than backing it out after the bookworm release. > I think both you and I support that. Any progress here? If this issue should be fixed for bookworm, time is running short. Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi, is there any update on fixing this issue before the bookworm release? I stumbled upon this bug report trying to fix #1032418, which is a rather grave bug. zcfan is one of the 37 packages affected. Because of this issue, dh_installsystemd does not generate a .postrm file to stop the service, so when a user installs zcfan, and after that thinkfan, zcfan is removed, but the service still runs. Since there are now two services controlling the fan speed, it will cause unpredictable behaviour and potentially HW damage. Regards, Lee
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Michael" == Michael Biebl writes: Michael> If a service is not supposed to be enabled, then an Michael> override for dh_installsystemd is the correct solution, Michael> setting --no-enable, but not by moving it into a Michael> subpackage. Sorry, I was imprecise. Imagine something like a webserver. You might well want to install the web server binary so you can run it as a user for development testing an app or for sharing files. But you might also want to install it as a system service. I think two options are viable depending on factors like whether some dependencies want to know that it is running as a system service and how common each configuration will be: * Install a disabled unit by default but keep everything into one package * or move the system service unit into its own package. If you just want the binary you install one package, but if you want the system service, you install the package containing the unit. In this case the unit is enabled by default. If we were to move units back from /usr/lib/systemd/system to /lib/systemd/system, the second case would potentially trigger the dpkg bug. But: Michael> I also don't see a good reason, why a unit file, once Michael> installed in /usr/lib/systemd/system should ever move back Michael> to /lib/systemd/system. I agree with you here. This requires keeping the debhelper change rather than backing it out after the bookworm release. I think both you and I support that. signature.asc Description: PGP signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Tue, 28 Feb 2023 23:54:15 +0100 Michael Biebl wrote: > Am 28.02.23 um 21:48 schrieb Sam Hartman: > > >> Moreover, I suspect in a number of the cases related to this > > >> current bug, replaces will be likely. I suspect that in some of > > >> the cases where units have been introduced that are disabled > > >> currently, but will be enabled by the dh_installsystemd change, > > >> we will discover we'd like those units disabled in some > > >> configurations. A logical way to handle that may be to split out > > >> the units into separate packages. That makes the replaces > > >> interacts with file moves class of bugs more likely in this > > >> situation than average. > > > > Sebastian> The TC advice refers to files moving between packages > > Sebastian> which wouldn't be the case here (at least not in > > Sebastian> general). > > > > Not in general, but I think that these systemd units will be more > > likely than average to move packages. > > > > These units have been sitting around more or less doing nothing for > > months. > > And in most cases we don't have bugs. > > > > I'm imagining the following situation: > > > > * We make the debhelper change > > > > * unit b in package a starts running > > > > * Users complain that they don't really always want that. > > > > * We release > > > > * unit b is moved back to /lib/systemd/system > > > > * Later the complaints get serious enough that package a splits into a > > and a-daemon, a-daemon replaces/breaks a<< version-of-split. a- daemon > > now has b. > > If a service is not supposed to be enabled, then an override for > dh_installsystemd is the correct solution, setting --no-enable, but not > by moving it into a subpackage. > > I also don't see a good reason, why a unit file, once installed in > /usr/lib/systemd/system should ever move back to /lib/systemd/system. Also it is trivial for users to disable or mask units, so there is really no reason to move them to subpackages. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Am 28.02.23 um 21:48 schrieb Sam Hartman: >> Moreover, I suspect in a number of the cases related to this >> current bug, replaces will be likely. I suspect that in some of >> the cases where units have been introduced that are disabled >> currently, but will be enabled by the dh_installsystemd change, >> we will discover we'd like those units disabled in some >> configurations. A logical way to handle that may be to split out >> the units into separate packages. That makes the replaces >> interacts with file moves class of bugs more likely in this >> situation than average. Sebastian> The TC advice refers to files moving between packages Sebastian> which wouldn't be the case here (at least not in Sebastian> general). Not in general, but I think that these systemd units will be more likely than average to move packages. These units have been sitting around more or less doing nothing for months. And in most cases we don't have bugs. I'm imagining the following situation: * We make the debhelper change * unit b in package a starts running * Users complain that they don't really always want that. * We release * unit b is moved back to /lib/systemd/system * Later the complaints get serious enough that package a splits into a and a-daemon, a-daemon replaces/breaks a<< version-of-split. a-daemon now has b. If a service is not supposed to be enabled, then an override for dh_installsystemd is the correct solution, setting --no-enable, but not by moving it into a subpackage. I also don't see a good reason, why a unit file, once installed in /usr/lib/systemd/system should ever move back to /lib/systemd/system. Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
>> Moreover, I suspect in a number of the cases related to this >> current bug, replaces will be likely. I suspect that in some of >> the cases where units have been introduced that are disabled >> currently, but will be enabled by the dh_installsystemd change, >> we will discover we'd like those units disabled in some >> configurations. A logical way to handle that may be to split out >> the units into separate packages. That makes the replaces >> interacts with file moves class of bugs more likely in this >> situation than average. Sebastian> The TC advice refers to files moving between packages Sebastian> which wouldn't be the case here (at least not in Sebastian> general). Not in general, but I think that these systemd units will be more likely than average to move packages. These units have been sitting around more or less doing nothing for months. And in most cases we don't have bugs. I'm imagining the following situation: * We make the debhelper change * unit b in package a starts running * Users complain that they don't really always want that. * We release * unit b is moved back to /lib/systemd/system * Later the complaints get serious enough that package a splits into a and a-daemon, a-daemon replaces/breaks a<< version-of-split. a-daemon now has b. * Now we have a potential problem where we have both a file move and a replaces, and b can disappear on an upgrade from a pre-split a to a+a-daemon after the split. Whether that happens depends on dpkg's order of operations The nasty thing about this situation is that moving b from /usr to / can happen at very different points in the release cycle from doing the split and adding the replaces. You need to remember whether during the release cycle you've had any moves that can involve aliased paths. If you have, you must not later in the release cycle introduce replaces. So, in general, we'll be fine. But in specific I don't think we'll be fine that removing the debhelper code will be a sane thing to do. signature.asc Description: PGP signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-28 10:26:07 -0700, Sam Hartman wrote: > > "Sebastian" == Sebastian Ramacher writes: > > Sebastian> Can you expand your concern? I expect that this issue > Sebastian> goes away as soon as we can assume that all systems are > Sebastian> /usr-merged. At that point I expect that we are able to > Sebastian> drop the workaround from debhelper and packages can move > Sebastian> the files to the expected location without issues. > > Quoting the TC advice: > > > > > - On merged-/usr systems, there is a possible failure mode involving > > files being moved between packages (with Replaces) during the same > > release cycle that their logical location is changed from the root > > filesystem to the corresponding aliased directory in /usr, which > > can > > result in the affected file disappearing. This can be avoided by > > not > > changing the file's logical location until the beginning of the > > Debian > > 13 development cycle, after the transition to merged-/usr is > > complete. > > > I think it is only true that files can move in the Debian 13 cycle if > the dpkg issues are fixed. > If dpkg is not fixed, then the issue with replaces interacting badly > with file moves will still exist. > > Moreover, I suspect in a number of the cases related to this current > bug, replaces will be likely. I suspect that in some of the cases where > units have been introduced that are disabled currently, but will be > enabled by the dh_installsystemd change, we will discover we'd like > those units disabled in some configurations. A logical way to handle > that may be to split out the units into separate packages. > That makes the replaces interacts with file moves class of bugs more > likely in this situation than average. The TC advice refers to files moving between packages which wouldn't be the case here (at least not in general). Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Sebastian" == Sebastian Ramacher writes: Sebastian> Can you expand your concern? I expect that this issue Sebastian> goes away as soon as we can assume that all systems are Sebastian> /usr-merged. At that point I expect that we are able to Sebastian> drop the workaround from debhelper and packages can move Sebastian> the files to the expected location without issues. Quoting the TC advice: > > - On merged-/usr systems, there is a possible failure mode involving > files being moved between packages (with Replaces) during the same > release cycle that their logical location is changed from the root > filesystem to the corresponding aliased directory in /usr, which > can > result in the affected file disappearing. This can be avoided by > not > changing the file's logical location until the beginning of the > Debian > 13 development cycle, after the transition to merged-/usr is > complete. I think it is only true that files can move in the Debian 13 cycle if the dpkg issues are fixed. If dpkg is not fixed, then the issue with replaces interacting badly with file moves will still exist. Moreover, I suspect in a number of the cases related to this current bug, replaces will be likely. I suspect that in some of the cases where units have been introduced that are disabled currently, but will be enabled by the dh_installsystemd change, we will discover we'd like those units disabled in some configurations. A logical way to handle that may be to split out the units into separate packages. That makes the replaces interacts with file moves class of bugs more likely in this situation than average. --Sam signature.asc Description: PGP signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-28 07:28:18 -0700, Sam Hartman wrote: > > "Sebastian" == Sebastian Ramacher writes: > > Sebastian> On 2023-02-23 11:12:00 -0700, Sam Hartman wrote: > >> > "Sean" == Sean Whitton writes: > >> > Sean> Hello, > Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: > >> > >> >> Unless I am missing something, having dh_installsystemd look > >> at >> the service files in /usr/lib is the only viable solution > >> for >> bullseye -> bookworm. We could fix individual packages > >> that >> didn't include those files in bullseye, but for all the > >> others we >> are unable to move the files from /usr/lib to /lib. > >> > Sean> You're saying we can't move them in that case because the TC > Sean> resolution says no moving /usr/lib->/lib ? Or some other > Sean> reason? I thought we only said that files couldn't move in > Sean> the other direction. > >> > >> Well, there is the underlying technical issue that made the TC > >> resolution reasonable. Moving paths between aliased locations > >> plus replaces will always produce behavior that is predictable > >> and potentially bad with the current dpkg. It's independent on > >> whether it's /usr/lib or /lib on source or destination. > >> > >> I agree with the analysis and believe that having > >> dh_installsystemd look in /usr/lib/systemd is the option least > >> likely to create breakage. > > Sebastian> As there were no follow ups to this message, I think we > Sebastian> reached concensus on the issue. Thus, let's have that > Sebastian> implemented in dh_installsystemd for bookworm and the > Sebastian> affected packages binNMUs. > > I agree roughly with this part. > We may run into bugs where it turns out having a particular unit enabled > doesn't actually provide the behavior we were looking for. > I.E. we've been happy without the unit for a while now, and it turns out > that was the right state. > I suspect the number of such bugs will be small, and we'll just have to > find them through testing. > > Sebastian> Once the release cycle of > Sebastian> trixie starts, the workaround for bookworm can be > Sebastian> dropped. > > I don't think that's correct unless dpkg is fixed. > Once we've shipped with the unit in /usr/lib/systemd, we cannot move to > /lib/systemd without potentially triggering the dpkg situation. > So, I don't see how we can ever remove this. Can you expand your concern? I expect that this issue goes away as soon as we can assume that all systems are /usr-merged. At that point I expect that we are able to drop the workaround from debhelper and packages can move the files to the expected location without issues. Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Sebastian" == Sebastian Ramacher writes: Sebastian> On 2023-02-23 11:12:00 -0700, Sam Hartman wrote: >> > "Sean" == Sean Whitton writes: >> Sean> Hello, Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: >> >> >> Unless I am missing something, having dh_installsystemd look >> at >> the service files in /usr/lib is the only viable solution >> for >> bullseye -> bookworm. We could fix individual packages >> that >> didn't include those files in bullseye, but for all the >> others we >> are unable to move the files from /usr/lib to /lib. >> Sean> You're saying we can't move them in that case because the TC Sean> resolution says no moving /usr/lib->/lib ? Or some other Sean> reason? I thought we only said that files couldn't move in Sean> the other direction. >> >> Well, there is the underlying technical issue that made the TC >> resolution reasonable. Moving paths between aliased locations >> plus replaces will always produce behavior that is predictable >> and potentially bad with the current dpkg. It's independent on >> whether it's /usr/lib or /lib on source or destination. >> >> I agree with the analysis and believe that having >> dh_installsystemd look in /usr/lib/systemd is the option least >> likely to create breakage. Sebastian> As there were no follow ups to this message, I think we Sebastian> reached concensus on the issue. Thus, let's have that Sebastian> implemented in dh_installsystemd for bookworm and the Sebastian> affected packages binNMUs. I agree roughly with this part. We may run into bugs where it turns out having a particular unit enabled doesn't actually provide the behavior we were looking for. I.E. we've been happy without the unit for a while now, and it turns out that was the right state. I suspect the number of such bugs will be small, and we'll just have to find them through testing. Sebastian> Once the release cycle of Sebastian> trixie starts, the workaround for bookworm can be Sebastian> dropped. I don't think that's correct unless dpkg is fixed. Once we've shipped with the unit in /usr/lib/systemd, we cannot move to /lib/systemd without potentially triggering the dpkg situation. So, I don't see how we can ever remove this. signature.asc Description: PGP signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-23 11:12:00 -0700, Sam Hartman wrote: > > "Sean" == Sean Whitton writes: > > Sean> Hello, > Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: > > >> Unless I am missing something, having dh_installsystemd look at > >> the service files in /usr/lib is the only viable solution for > >> bullseye -> bookworm. We could fix individual packages that > >> didn't include those files in bullseye, but for all the others we > >> are unable to move the files from /usr/lib to /lib. > > Sean> You're saying we can't move them in that case because the TC > Sean> resolution says no moving /usr/lib->/lib ? Or some other > Sean> reason? I thought we only said that files couldn't move in > Sean> the other direction. > > Well, there is the underlying technical issue that made the TC > resolution reasonable. > Moving paths between aliased locations plus replaces will always > produce behavior that is predictable and potentially bad with the > current dpkg. > It's independent on whether it's /usr/lib or /lib on source or > destination. > > I agree with the analysis and believe that having dh_installsystemd look > in /usr/lib/systemd is the option least likely to create breakage. As there were no follow ups to this message, I think we reached concensus on the issue. Thus, let's have that implemented in dh_installsystemd for bookworm and the affected packages binNMUs. Once the release cycle of trixie starts, the workaround for bookworm can be dropped. Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On Thu, 23 Feb 2023 11:12:00 -0700 Sam Hartman wrote: > > "Sean" == Sean Whitton writes: > > Sean> Hello, > Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: > > >> Unless I am missing something, having dh_installsystemd look at > >> the service files in /usr/lib is the only viable solution for > >> bullseye -> bookworm. We could fix individual packages that > >> didn't include those files in bullseye, but for all the others we > >> are unable to move the files from /usr/lib to /lib. > > Sean> You're saying we can't move them in that case because the TC > Sean> resolution says no moving /usr/lib->/lib ? Or some other > Sean> reason? I thought we only said that files couldn't move in > Sean> the other direction. > > Well, there is the underlying technical issue that made the TC > resolution reasonable. > Moving paths between aliased locations plus replaces will always > produce behavior that is predictable and potentially bad with the > current dpkg. > It's independent on whether it's /usr/lib or /lib on source or > destination. > > I agree with the analysis and believe that having dh_installsystemd look > in /usr/lib/systemd is the option least likely to create breakage. If those files have always been shipped in /usr then yes, I agree we should leave them there. We might have a problem if they were in /lib in bullseye though, but am I correct in understanding that this is not the case for any of the highlighted packages? -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Sean" == Sean Whitton writes: Sean> Hello, Sean> On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: >> Unless I am missing something, having dh_installsystemd look at >> the service files in /usr/lib is the only viable solution for >> bullseye -> bookworm. We could fix individual packages that >> didn't include those files in bullseye, but for all the others we >> are unable to move the files from /usr/lib to /lib. Sean> You're saying we can't move them in that case because the TC Sean> resolution says no moving /usr/lib->/lib ? Or some other Sean> reason? I thought we only said that files couldn't move in Sean> the other direction. Well, there is the underlying technical issue that made the TC resolution reasonable. Moving paths between aliased locations plus replaces will always produce behavior that is predictable and potentially bad with the current dpkg. It's independent on whether it's /usr/lib or /lib on source or destination. I agree with the analysis and believe that having dh_installsystemd look in /usr/lib/systemd is the option least likely to create breakage.
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hello, On Wed 22 Feb 2023 at 09:55AM +01, Sebastian Ramacher wrote: > Unless I am missing something, having dh_installsystemd look at the > service files in /usr/lib is the only viable solution for bullseye -> > bookworm. We could fix individual packages that didn't include those > files in bullseye, but for all the others we are unable to move the > files from /usr/lib to /lib. You're saying we can't move them in that case because the TC resolution says no moving /usr/lib->/lib ? Or some other reason? I thought we only said that files couldn't move in the other direction. Are there any of the 35 packages that did in fact ship them in /usr in bullseye? -- Sean Whitton signature.asc Description: PGP signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-21 15:43:08 +0100, Michael Biebl wrote: > Hi Niels > > On Tue, 21 Feb 2023 10:47:09 +0100 Niels Thykier wrote: > > > Sorry for being terse, I should be working on something else right now > > but prioritized a short message over nothing. > > > > Duplicate of #995569. > > Sorry, missed that... > > My concerns from back then still applies and I > > will not implement this feature until they are resolved. For the record, > > I do not feel the tech-ctte's resolution back then answered my question. > > > > Additionally, we are in the bookworm freeze where toolchains are frozen > > and have been for a month now. I am also not going to implement this > > change for bookwork unless there is an agreement from the release team > > in place that this is the direction we want to go (I do not have time to > > look at that discussion right now either). > > Looping in the release team. > > Quoting Helmut from IRC: > > helmut > 'I am indeed wondering whether the ctte's acceptance of "usr-is-merged is > pulled by init-system-helpers" would be sufficient to address nthykier's > concerns. That's new compared to his earlier rejection.' > > > I'm currently evaluating what the best course of action is here. > > The patch for dh_installsystemd would be quite simple and then we'd mostly > need a couple of binNMUs. In Trixie we will need that anyway and I assume > for backports it would be beneficial as well. > This all speaks in favor of changing dh_installsystemd. > > The alternative is to basically have 35 RC bugs against affected packages > and fixing those individually by moving the files to /lib Unless I am missing something, having dh_installsystemd look at the service files in /usr/lib is the only viable solution for bullseye -> bookworm. We could fix individual packages that didn't include those files in bullseye, but for all the others we are unable to move the files from /usr/lib to /lib. Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
On 2023-02-21 09:45:34 -0700, Sam Hartman wrote: > > "Michael" == Michael Biebl writes: > Michael> Excluding packages that only ship overrides/drop-ins, this > Michael> makes 37 affected packages in bookworm. > > If I'm understanding this issue correctly, the concern would be a > package that moved from /lib/systemd/system to /usr/lib/systemd/system. > Under the TC resolution, that should not be happening for bookworm. > > At least some of those packages are new services that have never been in > /lib/systemd/system. I believe for example pam is in that set. > > That's presumably not going to break something in the way that a file > moving between /lib and /usr/lib is. > But we don't want to encourage that movement. > > It seems like knowing how many incorrect moves we've had would also be > valuable--how many things that used to be in /lib/systemd but are now > appearing in /usr/lib. None as far as I can tell. Cheers -- Sebastian Ramacher
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Michael" == Michael Biebl writes: Michael> Am 21.02.23 um 17:45 schrieb Sam Hartman: >>> "Michael" == Michael Biebl writes: Michael> Excluding packages that only ship overrides/drop-ins, this Michael> makes 37 affected packages in bookworm. >> >> If I'm understanding this issue correctly, the concern would be a >> package that moved from /lib/systemd/system to >> /usr/lib/systemd/system. Michael> Well, not really. I'm concerned about packages shipping Michael> files in /usr/lib/systemd/system and expecting that those Michael> services are properly enabled/started/restarted/stopped. I appreciate that is your concern. However, it would be easier to work with you if you expressed empathy and understanding for the other related concerns in the space. My understanding is that the reason this is not a trivially accepted patch is related to usrmerge and the issue I brought up. Have I got that right?
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Am 21.02.23 um 17:45 schrieb Sam Hartman: "Michael" == Michael Biebl writes: Michael> Excluding packages that only ship overrides/drop-ins, this Michael> makes 37 affected packages in bookworm. If I'm understanding this issue correctly, the concern would be a package that moved from /lib/systemd/system to /usr/lib/systemd/system. Well, not really. I'm concerned about packages shipping files in /usr/lib/systemd/system and expecting that those services are properly enabled/started/restarted/stopped. OpenPGP_signature Description: OpenPGP digital signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
> "Michael" == Michael Biebl writes: Michael> Excluding packages that only ship overrides/drop-ins, this Michael> makes 37 affected packages in bookworm. If I'm understanding this issue correctly, the concern would be a package that moved from /lib/systemd/system to /usr/lib/systemd/system. Under the TC resolution, that should not be happening for bookworm. At least some of those packages are new services that have never been in /lib/systemd/system. I believe for example pam is in that set. That's presumably not going to break something in the way that a file moving between /lib and /usr/lib is. But we don't want to encourage that movement. It seems like knowing how many incorrect moves we've had would also be valuable--how many things that used to be in /lib/systemd but are now appearing in /usr/lib.
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
For bookworm we have $ apt-file search -x ^/usr/lib/systemd/system/ amazon-ec2-net-utils: /usr/lib/systemd/system/policy-routes@.service amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.service amazon-ec2-net-utils: /usr/lib/systemd/system/refresh-policy-routes@.timer arno-iptables-firewall: /usr/lib/systemd/system/arno-iptables-firewall.service boinc-client: /usr/lib/systemd/system/boinc-client.service booth: /usr/lib/systemd/system/booth-arbitrator.service caddy: /usr/lib/systemd/system/caddy-api.service caddy: /usr/lib/systemd/system/caddy.service ceph-iscsi: /usr/lib/systemd/system/rbd-target-api.service ceph-iscsi: /usr/lib/systemd/system/rbd-target-gw.service cfengine3: /usr/lib/systemd/system/cf-apache.service cfengine3: /usr/lib/systemd/system/cf-execd.service cfengine3: /usr/lib/systemd/system/cf-hub.service cfengine3: /usr/lib/systemd/system/cf-monitord.service cfengine3: /usr/lib/systemd/system/cf-postgres.service cfengine3: /usr/lib/systemd/system/cf-reactor.service cfengine3: /usr/lib/systemd/system/cf-runalerts.service cfengine3: /usr/lib/systemd/system/cf-serverd.service cfengine3: /usr/lib/systemd/system/cfengine3.service cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.service cloudflare-ddns: /usr/lib/systemd/system/cloudflare-ddns.timer debomatic: /usr/lib/systemd/system/debomatic.service drkonqi: /usr/lib/systemd/system/drkonqi-coredump-processor@.service fail2ban: /usr/lib/systemd/system/fail2ban.service fapolicyd: /usr/lib/systemd/system/fapolicyd.service freedombox: /usr/lib/systemd/system/avahi-daemon.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/bind9.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/calibre-server-freedombox.service freedombox: /usr/lib/systemd/system/coturn.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/deluged.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/freedombox-manual-upgrade.service freedombox: /usr/lib/systemd/system/janus.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/matrix-synapse.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/mediawiki-jobrunner.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/nmbd.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/plinth.service freedombox: /usr/lib/systemd/system/quasselcore.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/shadowsocks-libev-local@.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/smbd.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/syncthing@syncthing.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/transmission-daemon.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/tt-rss.service.d/freedombox.conf freedombox: /usr/lib/systemd/system/wordpress-freedombox.service freedombox: /usr/lib/systemd/system/wordpress-freedombox.timer freedombox: /usr/lib/systemd/system/zramswap.service.d/freedombox.conf fwknop-apparmor-profile: /usr/lib/systemd/system/usr.sbin.fwknopd gammu-smsd: /usr/lib/systemd/system/gammu-smsd.service libpam-modules-bin: /usr/lib/systemd/system/pam_namespace.service mpd: /usr/lib/systemd/system/mpd.service mpd: /usr/lib/systemd/system/mpd.socket mpdscribble: /usr/lib/systemd/system/mpdscribble.service nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex-ws.service nordugrid-arc-arex: /usr/lib/systemd/system/arc-arex.service nordugrid-arc-datadelivery-service: /usr/lib/systemd/system/arc-datadelivery-service.service nordugrid-arc-gridftpd: /usr/lib/systemd/system/arc-gridftpd.service nordugrid-arc-hed: /usr/lib/systemd/system/arched.service nordugrid-arc-infosys-ldap: /usr/lib/systemd/system/arc-infosys-ldap-slapd.service nordugrid-arc-infosys-ldap: /usr/lib/systemd/system/arc-infosys-ldap.service nvme-cli: /usr/lib/systemd/system/nvmefc-boot-connections.service nvme-cli: /usr/lib/systemd/system/nvmf-autoconnect.service nvme-cli: /usr/lib/systemd/system/nvmf-connect.target nvme-cli: /usr/lib/systemd/system/nvmf-connect@.service pass-extension-tomb: /usr/lib/systemd/system/pass-close@.service pcscd: /usr/lib/systemd/system/pcscd.service pcscd: /usr/lib/systemd/system/pcscd.socket phog: /usr/lib/systemd/system/greetd.service.d/phog.conf powerman: /usr/lib/systemd/system/powerman.service pvpgn: /usr/lib/systemd/system/pvpgn.service python3-charon: /usr/lib/systemd/system/charon.service qbittorrent-nox: /usr/lib/systemd/system/qbittorrent-nox@.service shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-local@.service shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-redir@.service shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-server@.service shadowsocks-libev: /usr/lib/systemd/system/shadowsocks-libev-tunnel@.service systemd-oomd: /usr/lib/systemd/system/-.slice.d/10-oomd-root-slice-defaults.conf systemd-oomd: /usr/lib/systemd/system/user@.service.d/10-oomd-user-service-defaults.conf tcmu-runner:
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Hi Niels On Tue, 21 Feb 2023 10:47:09 +0100 Niels Thykier wrote: Sorry for being terse, I should be working on something else right now but prioritized a short message over nothing. Duplicate of #995569. Sorry, missed that... My concerns from back then still applies and I will not implement this feature until they are resolved. For the record, I do not feel the tech-ctte's resolution back then answered my question. Additionally, we are in the bookworm freeze where toolchains are frozen and have been for a month now. I am also not going to implement this change for bookwork unless there is an agreement from the release team in place that this is the direction we want to go (I do not have time to look at that discussion right now either). Looping in the release team. Quoting Helmut from IRC: helmut 'I am indeed wondering whether the ctte's acceptance of "usr-is-merged is pulled by init-system-helpers" would be sufficient to address nthykier's concerns. That's new compared to his earlier rejection.' I'm currently evaluating what the best course of action is here. The patch for dh_installsystemd would be quite simple and then we'd mostly need a couple of binNMUs. In Trixie we will need that anyway and I assume for backports it would be beneficial as well. This all speaks in favor of changing dh_installsystemd. The alternative is to basically have 35 RC bugs against affected packages and fixing those individually by moving the files to /lib Dear release team, could you please have a look at https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1031695 and share your opinion on how to proceed here. Regards, Michael OpenPGP_signature Description: OpenPGP digital signature
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Control: forcemerge 1031695 995569 Michael Biebl: Package: debhelper Version: 13.11.4 Severity: important X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org It appears we currently ship 35 packages in unstable installing 78 service files to /usr/lib/systemd/system which dh_installsystemd doesn't handle: [...] The alternative is to update all those 35 packages and make sure they install the files to /lib. Michael Sorry for being terse, I should be working on something else right now but prioritized a short message over nothing. Duplicate of #995569. My concerns from back then still applies and I will not implement this feature until they are resolved. For the record, I do not feel the tech-ctte's resolution back then answered my question. Additionally, we are in the bookworm freeze where toolchains are frozen and have been for a month now. I am also not going to implement this change for bookwork unless there is an agreement from the release team in place that this is the direction we want to go (I do not have time to look at that discussion right now either). Thanks, ~Niels
Bug#1031695: dh_installsystemd doesn't handle files in /usr/lib/systemd/system
Package: debhelper Version: 13.11.4 Severity: important X-Debbugs-Cc: pkg-systemd-maintain...@lists.alioth.debian.org It appears we currently ship 35 packages in unstable installing 78 service files to /usr/lib/systemd/system which dh_installsystemd doesn't handle: $ apt-file search -x ^/usr/lib/systemd/system | wc -l 78 $ apt-file search -x ^/usr/lib/systemd/system | cut -f1 -d':' | sort -u | wc -l 35 This means, those service files are not enabled and (re)started/stopped. I suspect this is the result of the attempt last year, to move those files to /usr where lintian warned for a while if files where installed to /lib, so package maintainers started to update their packaging to install in /usr instead. I think dh_installsystemd should pick up files from /usr/lib/systemd/system in list_installed_units() and then we could just rebuild those packages. The alternative is to update all those 35 packages and make sure they install the files to /lib. Michael
