Bug#552797: perl: dpkg-shlibdeps fails on suid-perl on i386

[Niko Tyni]

On Fri, Oct 30, 2009 at 02:33:39PM +1100, Brendan O'Dea wrote:
> On Wed, Oct 28, 2009 at 7:13 PM, Niko Tyni <ntyni at debian.org> wrote:
> >  http://git.debian.org/?p=perl/perl.git;a=commitdiff;h=063f225d0fdeca563c7906927fc30171c3684f70
> 
> "This makes sure the script runs with the system perl and not the new one."
> 
> Note that one of the reasons why perl has a slightly eccentric rules
> file is so that the package is able to be built on a system without
> any perl installed.  This was to allow new ports to bootstrap and is
> the reason why ./perl.static is used in that file rather than
> /usr/bin/perl.  It is entirely possible that bit-rot has made this no
> longer work, but it is still a useful goal to retain.
> 
> See debian/checkperl, which is invoked for the install rule.

Thanks.  I agree it's a useful goal. It looks like I didn't think this
fully through.  I'm pretty sure there was a real problem I was solving
with the commit rather than just cleaning up though.

It must have been related to building 5.10.1 on a 5.10.0 system.
ISTR the system 5.10.0 DynaLoader.pm or Config.pm choking when run with
a 5.10.1 interpreter. OTOH this had been done many times in the 5.8
series (pre-etch) so I wonder what changed.

Getting dpkg-shlibdeps to prepend the build directories to the include
paths would have been another way to fix this, but this one seemed
cleaner.

Note that as seen in this very bug, dpkg-shlibdeps failing doesn't
currently abort the build (although it arguably should), so the 
failures just lead to insufficient package dependencies, which
shouldn't be a big problem when bootstrapping a new architecture.

I'll revisit the issue and see if there's an easy way to deal with
the include path (just setting PERL5LIB didn't work IIRC).
-- 
Niko Tyni   ntyni at debian.org