Could Debian Perl team take over PDL?

[Sebastiaan Couwenberg]

Hi Niko,

> On Fri, Jun 17, 2016 at 02:51:11AM +0200, Sebastiaan Couwenberg wrote:
>> Only a few hardening lintian issues remain (mostly
>> no-fortify-functions), that I've not been able to resolve yet. More
>> importantly we should get the two binary-or-shlib-defines-rpath errors
>> resolved. The tests failures are also not fixed yet.

With the addition of libtest-{deep,exception}-perl to the build
dependencies several additional tests now succeed.

For the RPATH issue we may want consider this patch for ExtUtils::MakeMaker:

 https://bugzilla.redhat.com/attachment.cgi?id=552448

>From the patch:

"
 USE_MM_LD_RUN_PATH

 boolean
 The Fedora perl MakeMaker distribution differs from the standard
 upstream release in that it disables use of the MakeMaker generated
 LD_RUN_PATH by default, UNLESS this attribute is specified , or the
 USE_MM_LD_RUN_PATH environment variable is set during the MakeMaker
 run.

 The upstream MakeMaker will set the ld(1) environment variable
 LD_RUN_PATH to the concatenation of every -L ld(1) option directory
 in which a -l ld(1) option library is found, which is used as the
 ld(1) -rpath option if none is specified. This means that, if your
 application builds shared libraries and your MakeMaker application
 links to them, that the absolute paths of the libraries in the build
 tree will be inserted into the RPATH header of all MakeMaker generated
 binaries, and that such binaries will be unable to link to these
 libraries if they do not still reside in the build tree directories
 (unlikely) or in the system library directories (/lib or /usr/lib),
 regardless of any LD_LIBRARY_PATH setting. So if you specified
 -L../mylib -lmylib , and your 'libmylib.so' gets installed into
 /some_directory_other_than_usr_lib, your MakeMaker application will be
 unable to link to it, even if LD_LIBRARY_PATH is set to include
 /some_directory_other_than_usr_lib, because RPATH overrides
 LD_LIBRARY_PATH.

 So for Fedora MakeMaker builds LD_RUN_PATH is NOT generated by default
 for every link. You can still use explicit -rpath ld options or the
 LD_RUN_PATH environment variable during the build to generate an RPATH
 for the binaries.

 You can set the USE_MM_LD_RUN_PATH attribute to 1 on the MakeMaker
 command line or in the WriteMakefile arguments to enable generation of
 LD_RUN_PATH for every link command.

 USE_MM_LD_RUN_PATH will default to 1 (LD_RUN_PATH will be used) IF the
 $USE_MM_LD_RUN_PATH environment variable is set during a MakeMaker run.
"

On 06/17/2016 07:14 PM, Niko Tyni wrote:
> Thanks for your work, this is awesome!

You're welcome, I'm glad the work is appreciated.

> I skimmed through the pdl packaging in git, and a few things I noticed:
> 
> - the scantree.pl call in pdl.postinst can't work without
>   doc_dirlist.patch I think? It's passing in multiple directories but
>   the unpatched scantree.pl doesn't handle those

While reviewing the test failures and disabled patches today I confirmed
that too. I've re-enabled this patch along with some of the others, and
obsolete patches have been removed.

The removals include fix_manifest.patch which seems to have been
introduced to fix t/01-checkmanifest.t failure, which currently succeeds
but does report "missing files from MANIFEST". Ideally upstream drops
the debian directory from their tarballs so the MANIFEST files don't
need to reference it at all.

> - the existing slatec_default_integer_8.patch fixes all the test failures
>   expect t/minuit.t for me on amd64
> 
> - the existing minuit_default_integer_8.patch fixes the remaining one
> 
> - there's some trivial conflict between the new spelling-errors.patch
>   and minuit_default_integer_8.patch, resolved with the attached patch

Thanks for the patch, it's applied as part of the commit re-enabling the
default_integer_8 patches. Test failures are now no longer ignored to
find out which architectures still have issues.

> - 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.

Basic/Pod/Tips.pod documents the following for example:

"
  Help
    Use "help help" within perldl or pdl2 or use the "pdldoc" program
    from the command line for access to the PerlDL documentation. HTML
    versions of the pages should also be present, in the HtmlDocs/PDL
    directory of the PDL distribution. To find this directory, try the
    following

     pdl> foreach ( map{"$_/PDL/HtmlDocs"}@INC ) { p "$_\n" if -d $_ }
"

Basic/Pod/QuickStart.pod documents this foreach loop too.

The help_url subroutine in Doc/Doc/Perldl.pm does pretty much the same:

 sub help_url {
     local $_;
     foreach(@INC) {
         my $a = "$_/PDL/HtmlDocs/PDL/Index.html";
         if(-e $a) {
             return "file://$a";
         }
     }
 }

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.

> Hope this makes sense; I'm still far from a domain expert on the PDL stuff...

Me neither, but it seems a pretty straight forward Perl project so far.

Kind Regards,

Bas

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