On 2023-02-28 07:28:18 -0700, Sam Hartman wrote: > >>>>> "Sebastian" == Sebastian Ramacher <sramac...@debian.org> writes: > > Sebastian> On 2023-02-23 11:12:00 -0700, Sam Hartman wrote: > >> >>>>> "Sean" == Sean Whitton <spwhit...@spwhitton.name> 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
