Could Debian Perl team take over PDL?

[Sebastiaan Couwenberg]

On 06/18/2016 05:11 PM, Niko Tyni wrote:
> On Fri, Jun 17, 2016 at 11:50:34PM +0200, Sebastiaan Couwenberg wrote:
>  
>> For the RPATH issue we may want consider this patch for ExtUtils::MakeMaker:
>>
>>  https://bugzilla.redhat.com/attachment.cgi?id=552448
> 
> Hm. If I understand this correctly, we have
>   https://sources.debian.net/src/perl/5.22.2-1/debian/patches/debian/ld_run_path.diff/
> for mostly the same effect. It makes MakeMaker skip RPATH for "standard"
> library dirs. I'm not sure why that doesn't help here; I'm not aware
> of other Perl-related packages suffering of similar issues.
> 
> The 2.016-1~exp1 autoreject looks like the problem is with
> /usr/lib/gcc/x86_64-linux-gnu/5 which is apparently not a 'standard'
> library directory for some reason. Those are determined from
> $Config{libpth}, currently
> 
>  libpth='/usr/local/lib /usr/lib/gcc/x86_64-linux-gnu/5/include-fixed /usr/include/x86_64-linux-gnu /usr/lib /lib/x86_64-linux-gnu /lib/../lib /usr/lib/x86_64-linux-gnu /usr/lib/../lib /lib';
> 
> I'm guessing /usr/lib/gcc/x86_64-linux-gnu/5 comes from 'gfortran
> -print-libgcc-file-name' in debian/f77conf.pl.

That's correct.

> I suspect $Config{libpth} should contain /usr/lib/gcc/x86_64-linux-gnu/5
> too, but it's a horrible mess and the semantics are rather unclear...
> 
> I see you switched to using 'chrpath -d' for 2.016-1~exp2.
> I guess that's a tolerable workaround.

Yes, I think stripping RPATH is best we can do for now.

>>> - I was a bit surprised that doc_vendor_install.patch is now needed, but
>>>   apparently it's because upstream v2.007_03 added a "missing"
>>>   doc_vendor_install target to Makefile.PL. Conceptually, running
>>>   scantree.pl and mkhtmldoc.pl  during the package build/install
>>>   phase seems useless to me, as they will be re-run from the postinst
>>>   when the package is actually installed. I'm not sure if it would
>>>   make more sense to just patch that away from Makefile.PL? And
>>>   if we don't, I guess the results shouldn't go in places like
>>>   /usr/lib/x86_64-linux-gnu/perl5/5.22/PDL/HtmlDocs but rather under
>>>   /var ?
>>
>> FHS-wise /var seems more appropriate. Several bits of upstream code rely
>> on the HtmlDocs being in a subdirectory one of the paths in @INC.
> 
> I see that was the case for 2.007-5, but there appears to be no HtmlDocs
> directory at all there.
> 
>> We'll need to patch these to also try the directory under /var or use
>> that exclusively instead. The trigger already uses /var/lib/pdl/html,
>>
>> I guess /var/lib/pdl/HtmlDocs is most appropriate if we decide to change
>> to path.
> 
> Perhaps a symlink /usr/lib/x86_64-linux-gnu/perl5/5.22/PDL/HtmlDocs ->
> /var/lib/pdl/html would be enough?  That would be similar to what we
> already do for Index.pod and pdldoc.db.

The HTML files that pdl (2.007-5) installs in /var/lib/pdl/html are
installed in /usr/lib/x86_64-linux-gnu/perl5/5.22/PDL/HtmlDocs/PDL, the
PDL subdirectory is also hardcoded in the help_url subroutine in
Doc/Doc/Perldl.pm.

In ~exp3 I've disabled the doc_vendor_install to have postinst install
it in /var/lib/pdl/html, and symlinked /var/lib/pdl/html to
/usr/lib/x86_64-linux-gnu/perl5/5.22/PDL/HtmlDocs/PDL.

I've also fixed the remaining hardening issues for the pdl executable,
somewhere LDFLAGS get overwritten, so I've opted to call dpkg-buildflags
from the Makefile.

With todays changes I'm quite happy with the state of the pdl package.
I'll upload ~exp3 tomorrow, and I think we should upload pdl and its
rdeps to unstable next week.

Kind Regards,

Bas

-- 
 GPG Key ID: 4096R/6750F10AE88D4AF1
Fingerprint: 8182 DE41 7056 408D 6146  50D1 6750 F10A E88D 4AF1