Re: [debhelper-devel] "Rules-Requires-Root: no" vs ExtUtils::Install + dh_strip_nondeterminism
On Sat, Oct 28, 2017 at 02:21:37PM +0200, Axel Beckert wrote:
> 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 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.
I've come to the party a bit late and it looks like this question is
now moot, but just to confirm, I agree with your analysis here. I don't
see the behaviour of ExtUtils::MakeMake changing any time soon - the
behaviour makes perfect sense for a tool run locally as a user. It is
really dh_strip_nondeterminism which is fiddling with things later so it's
up to that tool to make sure it can do what it needs.
It does raise the concerns about what else might break if the installation
process thinks it's been run as a non-root user and does something which
is inappropriate for system-wide installation. I can well imagine
assumptions being made here in the real world. But I guess that is rare
enough that we would consider this a bug to be sorted out as and when
(as long as it's an opt-in change).
I read Niels' blog post and indeed reducing the reliance on fakeroot
sounds like an interesting idea.
Cheers,
Dominic.
Reply to: