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

Sat Oct 28 12:21:37 UTC 2017

Hi Niels,

Niels Thykier wrote:
> Thanks for testing R³ in the wild. :)

I really like that idea.

Do I understand it correctly that with "Rules-Requires-Root: no" the
root:root ownership is only set by dh_builddeb?

I initially thought quite a while about to which mailing list I should
send those findings and questions. debhelper-devel was probably the
right decision. But I fear we're now at some point where involving
multiple mailing lists is necessary. Hence I've expanded Niels'
quoting of my original mail a little to include some more context and
Cc'ed the Reproducible builds folks and the Debian Perl Team. I hope
nobody minds that additional archive redundancy. ;-)

(I'm currently reading this thread primarily via the debhelper-devel
list, so I'd be happy if you keep at least that list or myself in Cc.
TIA!)

My original mail with the full text can be found at
https://lists.alioth.debian.org/pipermail/debhelper-devel/2017-October/007241.html.

> > 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:
> > 
> > >    dh_strip_nondeterminism
> > > dh_strip_nondeterminism: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png: open: Permission denied at /usr/share/perl5/File/StripNondeterminism/handlers/png.pm line 60.
> > >
> > > debian/rules:5: recipe for target 'binary' failed
> > > make: *** [binary] Error 13
> > > dpkg-buildpackage: error: debian/rules binary subprocess returned exit status 2
> > 
> > The file in question is read-only, but belongs to the user trying to
> > build the package:
> > 
> > -r--r--r-- 1 abe abe 1749 Oct 27 22:48 debian/systray-mdstat/usr/share/perl5/auto/share/dist/systray-mdstat/harddrivespare.png
[...]
> > The culprit seems to be in ExtUtils::Install (part of
> > ExtUtils::MakeMaker) [...]'s install() subroutine which
> > later copies files from blib/ to $DESTDIR/$PREFIX/ which [...]
> > looks like a hardcoded 0444 plus executable bit where necessary:
> > 
> >     812                 $mode = 0444 | ( $mode & 0111 ? 0111 : 0 );
> >     813                 $mode = $mode | 0222
> >     814                     if $realtarget ne $targetfile;
> >     815                 _chmod( $mode, $targetfile, $verbose );
> > 
> > So this issue very likely affects a big percentage of all Perl
> > packages (if we want to switch them to "Rules-Requires-Root: no", too)
> > as ExtUtils::MakeMaker is one of the most popular if not the most
> > popular build system in the Perl world.
[...]
> > 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?
[...]
> Basically, I see three options that are viable and useful:
> 
>  1) Fix ExtUtils::MakeMaker to DTRT (assuming upstream agrees with our
>     choice of permissions)

Without knowing ExtUtils::MakeMaker upstream well, I doubt that Debian
will throw over established defaults in the Perl world. :-)

Anyone from the Debian Perl Team has a guess how realistic Niels' wish
is?

For me, those permissions though make sense, at least when installing
locally as a user: You don't want to mess by accident with your local
per-user installation (on which you probably rely on) — and those
files are not guarded by just being writable by an administrative
user.

>  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

Thanks for that link.

So that means if nowadays dh_strip_nondeterminism doesn't give any
output, it didn't have anything to fix, right? (Lamby, can you
confirm? :-) That'd be good to know!

>  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.

Yes, that was my first thought (and try). And because of digging in
there and building debhelper a few times for test purposes, I noticed
and later fixed all warnings emitted by the newest lintian release.
:-)

Now that I now a little bit more context, I see a fourth one, which is
a temporary hack for a temporary tool and hence would vanish with the
temporary tool without traces anywhere else — and it doesn't need any
per-package fixes:

4) dh_strip_nondeterminism could check if the file it tries to analyze
   is read-only and if so, do either:

   a) change the permissions so it can edit it, fix it (if necessary)
      and then set the permissions back as they were before. Probably
      easier to implement.

   b) copy the file to a temporary location with write permissions,
      check if it needs to change anything. If not, just stay
      silent and drop the temporary copy. If it needs to fix anything
      it forcibly copys the changed version back, maybe by first
      unlinking the old file (only needs directory write permissions)
      and set the permissions back to what they were with the original
      file. Probably cleaner.

Cc'ing the Reproducible builds folks for comments on that idea.

> 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.

Cc'ing the Debian Perl Team for that.

		Regards, Axel
-- 
 ,''`.  |  Axel Beckert <abe at debian.org>, https://people.debian.org/~abe/
: :' :  |  Debian Developer, ftp.ch.debian.org Admin
`. `'   |  4096R: 2517 B724 C5F6 CA99 5329  6E61 2FF9 CD59 6126 16B5
  `-    |  1024D: F067 EA27 26B9 C3FC 1486  202E C09E 1D89 9593 0EDE