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