<div dir="auto"><div><br><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Nov 11, 2021, 11:45 Johannes Schauer Marin Rodrigues <<a href="mailto:josch@debian.org">josch@debian.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi all,<br>
<br>
Quoting Felipe Sateler (2021-11-11 15:14:06)<br>
> Sorry for the delay.<br>
<br>
thank you for your reply. :)<br>
<br>
> I have not been able to look much into this either. I looked at the patch,<br>
> and it looks somewhat ok, even if a bit extensive.<br>
<br>
if desired, I can greatly reduce the size of the patch by removing the<br>
assertdpkgroot() and assertnotdpkgroot() functions. I used those to make sure<br>
that the paths as they are passed around in deb-systemd-helper are having<br>
DPKG_ROOT prepended only if desired and if yes, only once. Since our tests did<br>
not trigger any errors and produces bit-by-bit identical results, I assume that<br>
it works correctly and theoretically the two assert functions could be removed,<br>
thus reducing the size of the patch significantly.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">My concern is more the non-DRYness of it. What if a new path is added? Do I need to check dpkgroot or not? I think some abstraction is missing in the tools (that is, am I operating on the target or the host?)</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> From my own POV, I think the main issue is precisely that we have no way of<br>
> knowing if this patch would break things or not. Given the centrality of this<br>
> package, it makes for a slow patch inclusion process. Additionally, I'm not<br>
> very proficient in perl, which is the primary language here.<br>
<br>
For normal installations, the value of $DPKG_ROOT is the empty string. I think<br>
it's easy to see that in the normal case, the behaviour of the script would not<br>
change.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">This is the test I'd like. More precisely, that the tools are doing what they are supposed to do.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
> What could be very helpful is to actually have some CI that would give me<br>
> (some) certainty a given patch does not break anything. Would it be possible<br>
> to move (some) of that CI you mention into this repo?<br>
<br>
Yes, certainly. What kind of tests would you like? Right now, there are still<br>
six source packages that need patching so that the DPKG_ROOT approach works for<br>
the essential package set. Would you like me to add an autopkgtest that does<br>
the same thing our CI does, i.e. patches packages, compiles them and then<br>
builds a unstable chroot and makes sure that the chroot tarball is bit-by-bit<br>
identical to one produced without DPKG_ROOT?<br>
<br>
Or do you want tests for the normal case without DPKG_ROOT? Isn't piuparts<br>
doing installation testing already? What kind of tests would you like me to<br>
write for you?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto">Honestly I'm a bit uncomfortable here. It is my belief that those who do get to decide. Since I'm not doing much, I believe I don't get to block other's work.</div><div dir="auto"><br></div><div dir="auto">I'm thus inclined to merge, and if Johannes can help create a test suite, even better. Since it is very early in the release cycle, I think we can manage the risk. Michael, what do you think?</div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"></blockquote></div></div></div>