From owner-svn-src-head@FreeBSD.ORG Sun Jun 16 04:26:10 2013 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by hub.freebsd.org (Postfix) with ESMTP id 758516D6; Sun, 16 Jun 2013 04:26:10 +0000 (UTC) (envelope-from gjb@FreeBSD.org) Received: from onyx.glenbarber.us (onyx.glenbarber.us [199.48.134.227]) by mx1.freebsd.org (Postfix) with ESMTP id 49B9819EB; Sun, 16 Jun 2013 04:26:10 +0000 (UTC) Received: from glenbarber.us (kaos.glenbarber.us [71.224.221.174]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gjb) by onyx.glenbarber.us (Postfix) with ESMTPSA id 6B4E023F841; Sun, 16 Jun 2013 00:26:06 -0400 (EDT) DKIM-Filter: OpenDKIM Filter v2.8.3 onyx.glenbarber.us 6B4E023F841 Authentication-Results: onyx.glenbarber.us; dkim=none reason="no signature"; dkim-adsp=none Date: Sun, 16 Jun 2013 00:26:04 -0400 From: Glen Barber To: Peter Wemm Subject: Re: svn commit: r251794 - in head: . contrib/cvs etc etc/mtree gnu/usr.bin gnu/usr.bin/cvs share/doc/psd share/doc/psd/28.cvs share/mk tools/build/mk tools/build/options tools/tools/nanobsd/gateworks Message-ID: <20130616042604.GJ1692@glenbarber.us> References: <201306152029.r5FKT8S3012945@svn.freebsd.org> <51BCEBED.9060101@FreeBSD.org> <51BCFA1C.4030100@FreeBSD.org> <20130616031444.GE1692@glenbarber.us> <20130616032725.GF1692@glenbarber.us> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="j/HO4hzKTNbM1mOX" Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD 10.0-CURRENT amd64 User-Agent: Mutt/1.5.21 (2010-09-15) Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Eitan Adler , Bryan Drewery X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 16 Jun 2013 04:26:10 -0000 --j/HO4hzKTNbM1mOX Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Jun 15, 2013 at 09:02:56PM -0700, Peter Wemm wrote: > On Sat, Jun 15, 2013 at 8:27 PM, Glen Barber wrote: > > On Sat, Jun 15, 2013 at 08:20:58PM -0700, Peter Wemm wrote: > >> On Sat, Jun 15, 2013 at 8:14 PM, Glen Barber wrote: > >> > On Sat, Jun 15, 2013 at 08:06:03PM -0700, Peter Wemm wrote: > >> >> On Sat, Jun 15, 2013 at 4:34 PM, Bryan Drewery wrote: > >> >> > >> >> > There are build-time dependencies on cvs. This is just grepping m= y last > >> >> > (partial) exp-run logs for '/usr/bin/n?cvs' > >> >> > >> >> Where was this righteous indignation when the perl 5.14.2 -> 5.14 > >> >> directory rename abomination was unleashed? Why wasn't every perl > >> >> port micro version bumped? If ever there was a festering pile of > >> >> horse excrement, that was one. > >> >> > >> > > >> > Please see ports/sysutils/cfengine port for how we can start to avoid > >> > this insanity with such version bumps. All we need is a little bit = of > >> > testing, and someone to pull the trigger. > >> > >> What does cfengine have to do with two ports with the same version but > >> with different contents? > >> > > > > What two ports with the same version? lang/perl5.14.2 didn't exist. It > > was always lang/perl5.14. >=20 > No, the problem is things like: > p5-Net-DNS-0.72 Perl5 interface to the DNS resolver, > and dynamic updates > p5-Net-DNS-SEC-0.16 DNSSEC extensions to Net::DNS >=20 > The behind-the-scenes change caused "p5-Net-DNS-0.72" to have files in > different locations depending on when it was built. Then the @INC > paths don't match and stuff catches fire. >=20 > peter@canning[9:00pm]~-103> pkg info -l p5-Net-DNS-0.72 > ... > /usr/local/lib/perl5/site_perl/5.14.2/mach/Net/DNS/ZoneFile.pm > /usr/local/lib/perl5/site_perl/5.14.2/mach/auto/Net/DNS/.packlist > /usr/local/lib/perl5/site_perl/5.14.2/mach/auto/Net/DNS/DNS.bs > ... > and if I force rebuild it now, it has different contents with the same > version number. And it won't work unless you remember to do so. >=20 Right. So, I solved this problem over a year ago. Basically, using perl as the example, you have the master port lang/perl5, containing something like this: VERSIONS=3D 5.12 5.14 PERL_DEFAULT?=3D 5.14 PERL_MINOR?=3D 2 Now instead of p5-BLAH requiring lang/perl5.14 explicitly, it requires lang/perl5. So when PERL_DEFAULT changes (as a ports-global version bump), the PERL_MINOR is bumped as well, so all dependent ports "see" the version change. Or, in this case, PERL_MINOR itself changes from '2' to '4'; now the "parent" port version has changed, so dependent ports "see" that change as well. This also solves the problem of users needing to do things like changing port origins for major version bumps within the tree. For what it is worth, I've done testing with this specific thing over a year ago, and had success with apache, perl, php, ruby, postfix, and a few others. Glen --j/HO4hzKTNbM1mOX Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBCAAGBQJRvT5cAAoJEFJPDDeguUajZ9YH/303uE2qdQGFcfbHIxwqpW0w 3lCE5eBpTGilmd1o1VqtBBgLM4wuCBm/BB5dy8GtVQReExgwoj5hYU8xTpTwrtQm 08maK2SLXir7EsDBlJ7rQuxx/FZp5dssSyKanBB86kR/qvpex+L3CjDLOCOaqOLa Ut/YyNRblZAjRHFOQsCLLwGXFvIfW6L7vagSf0p3i7aWzRY7v1D3ddLsEZhiu9dp U8pO3Mu4/8ZjiSteFqc4bzNq8Fbdp/LQGlN6hBSgoRYcdir380FZVc9ETvDhwXP0 DlHIaV8/CaOK0+ZZoQKYwas6iDXgf0nfpM0wP/2dWqe0NTiF/RsXIbFsEqrDZyc= =pbzz -----END PGP SIGNATURE----- --j/HO4hzKTNbM1mOX--