[debhelper-devel] "Rules-Requires-Root: no" vs ExtUtils::Install + dh_strip_nondeterminism

[Niels Thykier]

Axel Beckert:
> Hi,
> 
> I just tried to build systray-mdstat (a Perl-written application which
> uses Dist::Zilla as build-system) with "Rules-Requires-Root: no" and
> it FTBFS as follows:
> 

Hi,

Thanks for testing R³ in the wild. :)

> [...]
> 
> The same strange behaviour with permissions seem to happen for scripts
> I install into /usr/bin/.
> 
> So IMHO it's not dh_strip_nondeterminism's fault, also because it
> perl's open() which indeed does bail out on trying to write to files
> with 444 (i.e. read-only) permissions (at least as unprivileged user).
> 
> I suspect that this fact will more or less affect most perl-based
> packages (as ExtUtils::MakeMaker is the most common build-system for
> Perl modules and applications) and we can't move them easily to
> "Rules-Requires-Root: no" without fixes inside debhelper or
> per-package workarounds.
> 
> [...]
> 
> Anyone another idea how to fix this in general and (more efficient)
> inside debhelper?
> 
> 		Regards, Axel
> 

Basically, I see three options that are viable and useful:

 1) Fix ExtUtils::MakeMaker to DTRT (assuming upstream agrees with our
    choice of permissions)

 2) Drop the use of dh_strip_nondeterminism for packages that embrace
    R³ (e.g. via an completely empty override target).  Please note that
    the strip-nondeterminism tooling is a temporary measure and will
    eventually be retired if possible.
    - Reference: https://tracker.debian.org/news/845042

 3) Hack around this in the debhelper build system as a temporary
    measure by "fixing" the permissions from EU::MakeMaker.  I believe
    this is the "perl_makemaker.pm" build system.

For me, the proper solution is 1) while 2) and 3) are work-arounds and
hacks.  But 2) makes the package build slightly faster and shows a
higher confidence in the reproducible properties of the package, where
3) makes it a bit slower and punts the strip-nondeterminism issue for
later.  Given how unlikely it is that strip-nondeterminism provides any
value for the average perl package:

 * I would recommend that the perl team to go with 2) we need a
   temporary measure while 1) is being fixed.

Thanks,
~Niels