On Thu, Jul 30, 2020 at 03:09:43PM +0200, mat...@debian.org wrote: > On Mon, Jul 27, 2020 at 11:17:37PM +0100, Dominic Hargreaves wrote: > > > > This smells like a bug in debhelper to me - perl policy says that perl > > > > should be /usr/bin/perl in shebangs, and I think the same should apply > > > > here. I'm amazed this hasn't bit us before, if I'm right (it's been like > > > > this since at least 2009, and probably forever). > > > > > > > > https://salsa.debian.org/debian/debhelper/-/blob/master/lib/Debian/Debhelper/Buildsystem/perl_build.pm#L44 > > > > > > Yes, that was the problem. After "perlbrew off" it works as expected. It > > > is an old problem indeed. > > > > > Filing this as a bug, with a proposed patch at > > https://salsa.debian.org/debian/debhelper/-/merge_requests/40 > > may I disagree? > I'll admit I never had to do it with perl, but every time people insists > on using full paths overrinding a program by hacking on PATH suddenly > becomes much harder.
I'm not persuaded by this argument. Debhelper is invoking perl in order to build Debian packages, whose contents must be compatible with /usr/bin/perl. Anyone hacking on something needing to change /usr/bin/perl is already going to need to deal with replacing /usr/bin/perl in order to test anything properly. > As usual, one would expect that their build system is sane, having a > non-working (or whatever was the problem there) `perl` during a build is > very much the fault of the person controlling that system, not of > debhelper. Not at all. Whilst release builds of packages should of course be built in clean environments, this is not a reason to break developer workflows when people happen to use a different perl for day to day activities. Dominic.
