Date: Tue, 25 Jun 2013 22:23:34 -0700 From: Jeremy Chadwick <jdc@koitsu.org> To: Kurt Jaeger <pi@opsec.eu> Cc: culot@freebsd.org, bapt@freebsd.org, az@freebsd.org, freebsd-ports@freebsd.org Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626052334.GA67802@icarus.home.lan> In-Reply-To: <20130626045051.GA82524@home.opsec.eu> References: <20130626001406.GA63314@icarus.home.lan> <20130626045051.GA82524@home.opsec.eu>
next in thread | previous in thread | raw e-mail | index | archive | help
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@koitsu.org | | UNIX Systems Administrator http://jdc.koitsu.org/ | | Making life hard for others since 1977. PGP 4BD6C0CB |
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130626052334.GA67802>