Recent Mk/bsd.perl.mk changes (r320679)

[Jeremy Chadwick]

On Wed, Jun 26, 2013 at 06:50:51AM +0200, Kurt Jaeger wrote:
> Hi!
> 
> > - Why the major.minor.patchlevel --> major.minor path change in the
> > first place.
> 
> Probably this:
> Currently, if the perl port is updated to the next patchlevel, one has to
> recompile a lot of ports.

That doesn't make any sense.

An example of what "we" (FreeBSD users/ports) had prior to r320679:

User has perl-5.12.3 installed (package or port, doesn't matter), and
also some perl module (we'll call it p5-Snakes-1.00).

User updates /usr/ports, and finds that lang/perl5.12 has been updated
to perl 5.12.4 -- this doesn't matter in the least, nothing forces them
to update to that, it's unnecessary unless the individual port mandates
it (via $PERL_LEVEL).

The user also sees p5-Snakes has been updated to 1.02, so the user
pkg_delete/deinstalls it, make installs, and now has p5-Snakes-1.02
(fully usable) on their system.  It Just Works(tm), built completely off
the existing perl-5.12.3 bits.

If the user wants to update to perl-5.12.4, yes, they will need to
reinstall all their ports -- and justifiably so.  Expanding on that:

There is no reason I'd assume a.b.c would necessarily be completely
compatible with a.b.c+1 or subsequent updates.  The two things that come
to mind with perl are perlxs and libperl.so (note that there is no .so.N
versioning scheme with perl .so bits).  The DBI/DBD layer comes to mind
here (and that degree of breakage would really upset FreeBSD users).

Perl as a language tries to be backwards-compatible as much as possible,
but AFAIK this is purely a language/operational compatibility; whether
or not the underlying libraries and ABI/API of the shared objects are
compatible between minor revisions is an assumption -- unless someone
can show me proof otherwise.

But even if they can show such proof, it's not justification for the
backwards-compatibility breakage in bsd.perl.mk

> One of my reference hosts still compiles, started approx. a week ago.

I understand, but prior to r320679, you wouldn't have had to do that
unless you chose to updated lang/perl5.xx.

Instead, what we have *right now* is something that makes assumptions
(see above paragraph) **and** breaks fresh FreeBSD installs where the
person chooses to install the perl package + update /usr/ports + install
a perl module from ports, **as well** as an existing system where an
admin just wants to update a perl module from ports.  This is for
present-day supported FreeBSD versions, not EOL!

I'm fine with the major.minor.patchlevel --> major.minor pathname
change, **as long** as shims in bsd.perl.mk are put in place to retain
use of major.minor.patchlevel paths if an older version of perl is
installed on the system.  Those shims were not written, and I want to
know why, because as I see it we *can* have it both ways.

-- 
| Jeremy Chadwick                                   jdc at koitsu.org |
| UNIX Systems Administrator                http://jdc.koitsu.org/ |
| Making life hard for others since 1977.             PGP 4BD6C0CB |