Re: 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 <sramacher@debian.org> writes:
>
> Sebastian> On 2023-02-23 11:12:00 -0700, Sam Hartman wrote:
> >> >>>>> "Sean" == Sean Whitton <spwhitton@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
Reply to: