Recent Mk/bsd.perl.mk changes (r320679)
jdc at koitsu.org
Wed Jun 26 05:23:56 UTC 2013
On Wed, Jun 26, 2013 at 06:50:51AM +0200, Kurt Jaeger wrote:
> > - 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 |
More information about the freebsd-ports