Binary archives for perl modules assume perl is built without threads

[cmconnelly (Claire Connelly)]

With perl5.12 @5.12.4_0+dtrace+shared+threads, the most recent subversion-perlbindings package ignores the existence of the threads variant on perl5.12 and installs its modules in a directory that is not part of Perl's path.

$ perl -MSVN::Core
Can't locate SVN/Core.pm in @INC (@INC contains:
/opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level
/opt/local/lib/perl5/site_perl/5.12.4
/opt/local/lib/perl5/vendor_perl/5.12.4/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.12.4
/opt/local/lib/perl5/5.12.4/darwin-thread-multi-2level
/opt/local/lib/perl5/5.12.4
/opt/local/lib/perl5/site_perl
/opt/local/lib/perl5/vendor_perl/5.12.3/darwin-thread-multi-2level
/opt/local/lib/perl5/vendor_perl/5.12.3
/opt/local/lib/perl5/vendor_perl .) at (eval 2) line 2.

but

$ port contents subversion-perlbindings | grep SVN/Core.pm
  /opt/local/lib/perl5/vendor_perl/5.12.4/darwin-multi-2level/SVN/Core.pm

where it should be in /opt/local/lib/perl5/site_perl/5.12.4/darwin-thread-multi-2level.

This issue breaks git svn along with anything else relying on Subversion's Perl bindings.

[ecronin (Eric Cronin)]

You are probably pulling a pre-built binary package from the buildbot, where perl5.12 has the default -shared-threads variants. Force the port to be built from source and it will install in the correct path:

Port subversion-perlbindings contains:
...
  /opt/local/lib/perl5/vendor_perl/5.12.3/darwin-thread-multi-2level/SVN/Base.pm
...

If you aren't using binary packages, uninstall any existing versions of subversion-perlbindings and re-install and it will go in the right directory (you have to do this with every perl package installed every time you change your active perl variants)

[cmconnelly (Claire Connelly)]

Aha—yes, that appears to be what was happening. It seems like many or most things still build from source, enough that I had no idea that MacPorts was pulling binary archives (and there is no clear indication that you're installing an archive rather than building it locally; for something like a Perl package that might just consist of some Perl code (and not need compilation), you'd be hard pressed to see a difference unless you were familiar with the build process for that particular package). (If you look closely at the output of the install command you can see that port fetches an archive rather than distfiles, and the install lines start with x rather than a.)

So there are actually two different bugs here:

1. Given that the binary archive builds don't cover every possible variation of the Perl package (at least), port should verify that the binary archive was built against a Perl with the same variants as the locally installed Perl port, and build from source if it wasn't.

2. The -s flag is not passed along to any dependency builds, so if you build, say, git-core +svn, which depends on p5.12-svn-simple, which depends on subversion-perlbindings, only git-core will be built with the -s flag, and the dependents will be installed from the broken archives.

and maybe even

3. MacPorts installation behavior changes to use binary archives without telling the end user.

For anyone else with this issue, I had to uninstall several packages, then clean, then reinstall each package in the dependency chain separately with the -s flag to force a build from source.

Specifically,

sudo port -v uninstall subversion @1.7.5_0+bash_completion+tools
sudo port -v uninstall git-core
sudo port -v uninstall p5.12-svn-simple
sudo port -v uninstall subversion-perlbindings
sudo port clean subversion subversion-perlbindings git-core p5.12-svn-simple
sudo port -v -s install subversion +bash_completion+tools
sudo port -v -s install subversion-perlbindings
sudo port -v -s uninstall p5.12-svn-simple
sudo port -v -s install git-core +credential_osxkeychain+doc+pcre+python27+svn
}}}.

To stop this sort of problem from happening again, I compared `/opt/local/etc/macports/macports.conf.default` to `/opt/local/etc/macports/macports.conf`, and ended up copying `macports.conf.default` to `macports.conf`, then edited `macports.conf` to change
{{{
# When to build ports from source. Default is 'ifneeded', which downloads an
# archive if available or builds from source otherwise. 'always' has the same
# effect as -s on the command line, and 'never' is likewise the same as -b.
#buildfromsource    ifneeded
}}}
to
{{{
buildfromsource     always
}}}
to force builds from source even if a binary archive is available.

[ecronin (Eric Cronin)]

There is actually

1a. All Perl module ports are "broken" in that the contents of the port with an identical name/version/variants vary (in incompatible ways) based on what perl port is active at the time the module is installed. As I said in the first comment, you have exactly the same issues in an all-source-build environment when you switch from perl -threads to perl +threads-- every installed perl package becomes silently broken with no indication that anything is wrong or how to fix it.

1b. The package being served up from the buildbot will always be incorrect for a significant number of users in a very confusing manner

Until 1a is addressed (see mailing list discussions recently about revamping our perl ports, hopefully this would finally be addressed as part of that) would a good solution to 1b be to use the "archive_sites {}" trick in the perl5 portgroup to prevent binary packages from the buildbot being downloaded? Most perl modules are a quick build, and it seems far better to make everyone spend a few more seconds installing p5.12-foo and getting something that works than to have half the users get broken packages like this ticket reported. And as a stopgap the perl ports should have a post_activate notes warning that all installed perl modules need reinstalling and what the command to do that is.

[jmroot (Joshua Root)]

Yes, since you can't depend on a variant, offering these options as variants in the perl ports is broken. See existing tickets #23089, #23993, #26323, etc. I may soon just put on my portmgr hat and unilaterally resolve them.