>>>>> "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.
Attachment:
signature.asc
Description: PGP signature