Bug#983421: init-system-helpers: please respect DPKG_ROOT when checking for /usr/sbin/policy-rc.d
Felipe Sateler
fsateler at debian.org
Fri Nov 12 15:37:01 GMT 2021
On Thu, Nov 11, 2021, 11:45 Johannes Schauer Marin Rodrigues <
josch at debian.org> wrote:
> Hi all,
>
> Quoting Felipe Sateler (2021-11-11 15:14:06)
> > Sorry for the delay.
>
> thank you for your reply. :)
>
> > 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.
>
> if desired, I can greatly reduce the size of the patch by removing the
> assertdpkgroot() and assertnotdpkgroot() functions. I used those to make
> sure
> that the paths as they are passed around in deb-systemd-helper are having
> DPKG_ROOT prepended only if desired and if yes, only once. Since our tests
> did
> not trigger any errors and produces bit-by-bit identical results, I assume
> that
> it works correctly and theoretically the two assert functions could be
> removed,
> thus reducing the size of the patch significantly.
>
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?)
> > 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.
>
> For normal installations, the value of $DPKG_ROOT is the empty string. I
> think
> it's easy to see that in the normal case, the behaviour of the script
> would not
> change.
>
This is the test I'd like. More precisely, that the tools are doing what
they are supposed to do.
> > 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?
>
> Yes, certainly. What kind of tests would you like? Right now, there are
> still
> six source packages that need patching so that the DPKG_ROOT approach
> works for
> the essential package set. Would you like me to add an autopkgtest that
> does
> the same thing our CI does, i.e. patches packages, compiles them and then
> builds a unstable chroot and makes sure that the chroot tarball is
> bit-by-bit
> identical to one produced without DPKG_ROOT?
>
> Or do you want tests for the normal case without DPKG_ROOT? Isn't piuparts
> doing installation testing already? What kind of tests would you like me to
> write for you?
>
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.
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?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/pkg-systemd-maintainers/attachments/20211112/96a9a6e6/attachment.htm>
More information about the Pkg-systemd-maintainers
mailing list