perl: remove subrelease number from lib path

[mojca (Mojca Miklavec)]

I would like to suggest fixing the perl ports in such a way that the files would be installed under

${prefix}/lib/perl5/5.18

rather than

${prefix}/lib/perl5/5.18.2

The problem is that libperl.dylib is supposed to be ABI-compatible between sub-versions, but it is moved to a different location and thus any binaries depending on dylib are broken and must be revbumped after perl update for no good reason.

Relevant lines from Configure:

    version=`echo $revision $patchlevel $subversion | \
      $awk '{ printf "%d.%d.%d\n", $1, $2, $3 }'`
    api_versionstring=`echo $api_revision $api_version $api_subversion | \
        $awk '{ printf "%d.%d.%d\n", $1, $2, $3 }'`

case "$installstyle" in
*lib/perl5*) set dflt privlib lib/$package/$version ;;
*); set dflt privlib lib/$version ;;
esac

A similar change would be welcome for the path where packages get installed to avoid the need for

configure.args-append "-D inc_version_list=\"5.18.0/${os.platform}-thread-multi${platsuffix} 5.18.0 \""

This might be a moot point if we decide to completely change the way Perl packages work, but this particular fix can be done easily. The big rewrite will take time.

[ryandesign (Ryan Carsten Schmidt)]

You might want to discuss these changes with the developers of perl to get their input. If including the patch version number in the path to libperl and the modules is not necessary, as you suggest, then the developers may want to make that change upstream. Or maybe the developers will explain why the patch version number is necessary after all.

[mojca (Mojca Miklavec)]

I still agree that we probably want to talk to the developers, but I went ahead and applied a patch r120890 to perl5.20. Given that the port is completely new anyway, we won't break anyone's functionality and if the idea turns out not to work ... well then we can revert it.

The problem with upstream is that they have a different model of installing and using Perl than MacPorts does and I understand why for them the model works and why they wouldn't want to switch to what I did, at least not by default. One installs one version of perl and keeps it there even after installing the next new version. But MacPorts removes the old version (and doesn't provide experimental versions) and there's where the problems start.

We need to make a strong case and request a new feature, so that they would add a new configure option.

I would suggest to apply the same change also to perl5.18. (Or maybe we'll change the way Perl works altogether anyway.)

[mojca (Mojca Miklavec)]

The patch in r120890 apparently broke modules for Perl 5.20. Can you please test the following patch?

_resources/port1.0/group/perl5-1.0.tcl

@@ -73 +73 @@
 default perl5.bin {${prefix}/bin/perl${perl5.major}}
 
 # define installation libraries as vendor location
-default perl5.lib {${prefix}/lib/perl5/vendor_perl/${perl5.version}}
+default perl5.lib {[perl5.extract_config vendorlib]}
 default perl5.bindir {${prefix}/libexec/perl${perl5.major}}
 default perl5.archlib {${perl5.lib}/${perl5.arch}}
 

[mojca (Mojca Miklavec)]

I committed this in r122521. Please test p5.20 for a bunch of modules of your choice and let me know if you experience any problems.

[mojca (Mojca Miklavec)]

Remove subrelease from perl5.18 and revbump or upgrade all p5.18-* ports

[mojca (Mojca Miklavec)]

As there were no major reported problems with p5.20 after the last fix, I'm attaching a fix to do the same with p5.18. I suspect that p5.16 might be removed soon anyway (once we have a stable 5.20 with all the modules available).

I didn't test all modules yet. Please test or review the patches. I would like to commit this soon since it's difficult to keep the patch in sync with trunk.

I plan to add p5.18 and p5.20 to other perl modules once this is committed. I would certainly like to get this patch in before 5.18 is added to other perl modules.

[mojca (Mojca Miklavec)]

There's one main question left though: should I attempt to get rid of subrelease number also for perl5.16? In that case I would do it in such a way that it would still look in old directories and it would be a bit more work to initially set up, but in my opinion it should either be done now (together with revbumps for the sake of 5.18) or "never".

The main question is whether we want to get rid of 5.16 in some not too distant future or not. If we want to keep it for longer time, we might want to change this for 5.16 as well. I wouldn't bother about older perl versions.

[mojca (Mojca Miklavec)]

In my above patch I have found a few minor glitches so far (I'll re-upload), but a few ports are broken:

• p5-ifeffit
• p5-libapreq2: requires mod_perl2, but that one is installed against 5.16 and as a consequence a module is missing (#42582)
• p5-pdl, p5-pdl-stats
• p5-sgmlspm
• p5-wx

[mojca (Mojca Miklavec)]

Not fully working patch to remove subrelease from perl5.16 while keeping the old paths in INC

[mojca (Mojca Miklavec)]

If we want to fix 5.16 and earlier, I would like to request help with the above patch for 5.16.

You may try to install Perl 5.16 and then run

/opt/local/bin/perl5.16 -e "print \"@INC\n\""

I get

/opt/local/lib/perl5/site_perl/5.16/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.16
/opt/local/lib/perl5/vendor_perl/5.16/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.16
/opt/local/lib/perl5/5.16/darwin-thread-multi-2level
/opt/local/lib/perl5/5.16
/opt/local/lib/perl5/site_perl/5.16
/opt/local/lib/perl5/vendor_perl/5.16
.

instead of all the other releases. Most probably that's because perl thinks that 5.16.1 is a newer version of perl compared to 5.16, but I might be wrong. This probably needs a fix in Configure.

This is only relevant if we decide to change Perl 5.16 and earlier. Modifying the INC path is desired/needed as a temporary(?) "workaround" before all > 1000 ports get revbumped.

I suspect the following code might be the culprit:

    if ($d->[1] lt $pversion) {
	if ($d->[1] ge $aversion) {
	    unshift(@inc_version_list, grep { -d } $d->[0]."/$archname", $d->[0]);
	}
	elsif ($d->[1] ge $vsn5005) {
	    unshift(@inc_version_list, grep { -d } $d->[0]);
	}
    }
    else {
	# Skip newer version.  I.e. don't look in
	# 5.7.0 if we're installing 5.6.1.
    }

In the other patch you can see the proposed changes for trunk. (I will fix some alignments that I added, but that is a purely cosmetical thing and can also wait. Alignment in perl modules is a mess in general anyway.) Before I make a new branch any review or testing is welcome.

[mojca (Mojca Miklavec)]

Leaving out patches for Perl 5.16: r123698 and r123699.

[mojca (Mojca Miklavec)]

Here are the build logs to help us monitor potential problems:

• 10.6: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/28477
• 10.7: ​https://build.macports.org/builders/buildports-lion-x86_64/builds/22316
• 10.8: ​https://build.macports.org/builders/buildports-mtln-x86_64/builds/16325
• 10.9: ​https://build.macports.org/builders/buildports-mavericks-x86_64/builds/5687

Problems so far (up to 1400 on 10.9):

• p5-wx (#44416, #44640)
• p5-opengl (cannot be built on the buildbot, but should work on client)
• p5-pdl (#44439), p5-pdl-stats (depends on p5-pdl)
• p5-cgi-alternatives (r123714 might fix this)
• p5-encoding-fixlatin-xs (only 5.8-5.12, TODO)
• p5-spiffy (#44630)
• p5-ifeffit (#44631)
• log2timeline (TODO)
• p5.8-compress-snappy (TODO)
• p5-sgmlspm (#44418)
• p5.8-perlmagick (at least on 10.7)
• p5-test-base (depends on p5-spiffy)
  • p5-extutils-xspp (depends on p5-test-base)
• p5.20-xml-entities (TODO; fails on 10.9, works on 10.6)
  • p5.20-mac-propertylist (depends on p5.20-xml-entities)
• p5.18-autodia (TODO; probably a dependency wasn't revbumped)
• p5-libapreq2

Others:

• p5-term-readkey (#44633, r123720)

[mojca (Mojca Miklavec)]

I need to check ​Potentially missing revbumps

[mojca (Mojca Miklavec)]

Another batch revbump in r123755. I hope that I have now covered all the ports that I accidentally missed earlier.

[pixilla (Bradley Giesbrecht)]

Cc Me!

[mojca (Mojca Miklavec)]

The other batch of builds:

• 10.6: ​https://build.macports.org/builders/buildports-snowleopard-x86_64/builds/28478
• 10.7: ​https://build.macports.org/builders/buildports-lion-x86_64/builds/22317
• 10.8: ​https://build.macports.org/builders/buildports-mtln-x86_64/builds/16326
• 10.9: ​https://build.macports.org/builders/buildports-mavericks-x86_64/builds/5688

Failed ports:

• p5.8-net-dns-resolver-programmable (#44645)

  This module requires Module::Build to install itself.
    Install Module::Build now from CPAN? [y] y
  ...
  [then keeps installing modules from CPAN and fails because of insufficient permissions]
  

• p5.20-io-tty (#44647; only fails on 10.6)
  • p5.20-ipc-run
    • p5.20-graphviz
    • p5.20-module-signature
    • p5.20-panotools-script
    • p5.20-dbd-pg

      /usr/bin/gcc-4.2 -c   -pipe -Os -fno-common -DPERL_DARWIN -I/opt/local/include -no-cpp-precomp -fno-strict-aliasing -fstack-protector -I/opt/local/include -arch x86_64 -O3   -DVERSION=\"1.11\" -DXS_VERSION=\"1.11\"  "-I/opt/local/lib/perl5/5.20/darwin-thread-multi-2level/CORE"  -DHAVE_DEV_PTMX -DHAVE_GRANTPT -DHAVE_OPENPTY -DHAVE_POSIX_OPENPT -DHAVE_PTSNAME -DHAVE_SIGACTION -DHAVE_STRLCPY -DHAVE_TERMIOS_H -DHAVE_TTYNAME -DHAVE_UNLOCKPT -DHAVE_UTIL_H Tty.c
      In file included from Tty.xs:61:
      /opt/local/lib/perl5/5.20/darwin-thread-multi-2level/CORE/util.h:69: error: redefinition of typedef ‘perl_drand48_t’
      /opt/local/lib/perl5/5.20/darwin-thread-multi-2level/CORE/util.h:69: error: previous declaration of ‘perl_drand48_t’ was here
      make: *** [Tty.o] Error 1
      make: Leaving directory `/opt/local/var/macports/build/_opt_mports_dports_perl_p5-io-tty/p5.20-io-tty/work/IO-Tty-1.11'
      Command failed:  cd "/opt/local/var/macports/build/_opt_mports_dports_perl_p5-io-tty/p5.20-io-tty/work/IO-Tty-1.11" && /usr/bin/make -j8 -w all
      Exit code: 2
      

• p5-time-y2038 (#30718)

Other unrelated failed ports:

• mpv
• sysdig

[mojca (Mojca Miklavec)]

I'm closing this ticket. I believe I covered all modules for 5.18. I opened new tickets or referenced existing ones for problems I experienced when building upgraded ports.

If you experience any other problems, let me know.