Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d

[Felipe Sateler]

Hi all,

On Wed, Nov 3, 2021 at 11:30 AM Michael Biebl <biebl at debian.org> wrote:

> On 23.10.21 11:12, Johannes Schauer Marin Rodrigues wrote:
> > Hi Michael,
> >
> > Quoting Johannes Schauer Marin Rodrigues (2021-09-24 21:11:26)
> >>> Didn't have time yet to look at this. Sorry.  From a cursory glance it
> >>> feels inelegant having to sprinkle env vars across everything.
> >>
> >> indeed, our patch to init-system-helpers is the largest of all the
> changes.
> >> The advantage of changing init-system-helpers is, that then we don't
> have to
> >> touch many other maintainer scripts instead. On the up side, the
> $DPKG_ROOT
> >> variable is empty during normal operation, so prepending $DPKG_ROOT in
> front of
> >> all paths is unlikely to break anything without
> --force-script-chrootless
> >> active.
> >>
> >> Do you have ideas how the diff could be improved? I added the
> assertdpkgroot
> >> and assertnotdpkgroot functions to make sure that I'm not accidentally
> working
> >> on paths that have already been modified or should not be modified.
> >>
> >>> This also feels like it could get easily broken when changes are made.
> So I'm
> >>> not too enthusiastic tbh.
> >>
> >> in case things break in the future, our CI job would catch that
> breakage and
> >> then I'd send you another patch. I see this like other efforts like
> cross
> >> building or reproducible builds. It's not your task to make sure it's
> not
> >> breaking but we run a CI system and send you patches once we observe a
> >> regression.
> >>
> >> Needless to say, if something unrelated breaks because of this change,
> I'm
> >> also here to work on fixing that.
> >
> > a month passed since my last mail to this bug. Is there anything else I
> can do
> > to help with this bug?
> >
>
> Unfortunately, I didn't find the time to further look into it.
>
> Luca, Felipe, Martin, what are your thoughts?
>
>
Sorry for the delay.

I have not been able to look much into this either. I looked at the patch,
and it looks somewhat ok, even if a bit extensive.

>From my own POV, I think the main issue is precisely that we have no way of
knowing if this patch would break things or not. Given the centrality of
this package, it makes for a slow patch inclusion process. Additionally,
I'm not very proficient in perl, which is the primary language here.

What could be very helpful is to actually have some CI that would give me
(some) certainty a given patch does not break anything. Would it be
possible to move (some) of that CI you mention into this repo?

-- 

Saludos,
Felipe Sateler
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20211111/c5a38cd7/attachment.htm>