Could Debian Perl team take over PDL?
Sebastiaan Couwenberg
sebastic at xs4all.nl
Sat Jun 18 22:16:06 UTC 2016
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
More information about the pkg-perl-maintainers
mailing list