On Sat, Jun 15, 2013 at 09:02:56PM -0700, Peter Wemm wrote: > On Sat, Jun 15, 2013 at 8:27 PM, Glen Barber <g...@freebsd.org> 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 <g...@freebsd.org> 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 <bdrew...@freebsd.org> > >> >> wrote: > >> >> > >> >> > There are build-time dependencies on cvs. This is just grepping my > >> >> > 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. > > 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 > > 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. > > 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. >
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= 5.12 5.14
PERL_DEFAULT?= 5.14
PERL_MINOR?= 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
pgpdPoca1afHc.pgp
Description: PGP signature
