From owner-freebsd-ports@FreeBSD.ORG Wed Jun 26 05:23:56 2013 Return-Path: Delivered-To: freebsd-ports@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) by hub.freebsd.org (Postfix) with ESMTP id B04C4ADF; Wed, 26 Jun 2013 05:23:56 +0000 (UTC) (envelope-from jdc@koitsu.org) Received: from relay5-d.mail.gandi.net (relay5-d.mail.gandi.net [217.70.183.197]) by mx1.freebsd.org (Postfix) with ESMTP id 35CC41E8E; Wed, 26 Jun 2013 05:23:55 +0000 (UTC) Received: from mfilter21-d.gandi.net (mfilter21-d.gandi.net [217.70.178.149]) by relay5-d.mail.gandi.net (Postfix) with ESMTP id BB1C241C088; Wed, 26 Jun 2013 07:23:38 +0200 (CEST) X-Virus-Scanned: Debian amavisd-new at mfilter21-d.gandi.net Received: from relay5-d.mail.gandi.net ([217.70.183.197]) by mfilter21-d.gandi.net (mfilter21-d.gandi.net [10.0.15.180]) (amavisd-new, port 10024) with ESMTP id MSGWwmyknCjF; Wed, 26 Jun 2013 07:23:37 +0200 (CEST) X-Originating-IP: 76.102.14.35 Received: from jdc.koitsu.org (c-76-102-14-35.hsd1.ca.comcast.net [76.102.14.35]) (Authenticated sender: jdc@koitsu.org) by relay5-d.mail.gandi.net (Postfix) with ESMTPSA id B911F41C079; Wed, 26 Jun 2013 07:23:36 +0200 (CEST) Received: by icarus.home.lan (Postfix, from userid 1000) id 0098273A1C; Tue, 25 Jun 2013 22:23:34 -0700 (PDT) Date: Tue, 25 Jun 2013 22:23:34 -0700 From: Jeremy Chadwick To: Kurt Jaeger Subject: Re: Recent Mk/bsd.perl.mk changes (r320679) Message-ID: <20130626052334.GA67802@icarus.home.lan> References: <20130626001406.GA63314@icarus.home.lan> <20130626045051.GA82524@home.opsec.eu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130626045051.GA82524@home.opsec.eu> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: culot@freebsd.org, bapt@freebsd.org, az@freebsd.org, freebsd-ports@freebsd.org X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 26 Jun 2013 05:23:56 -0000 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 |