Projects with multiple versions in our ports tree

[Doug Barton]

The bash thing today highlights a problem that's been buggin' me for a 
while now. We host a lot of third party projects that grow, fork, and 
diverge into various forms as time goes on. The autoconf/automake ports 
are probably the penultimate example of this, but I'm facing the same 
issue with the various versions of the BIND ports.

The way that we've traditionally handled this is to have one canonical 
"foo" port, with various "fooNN" versions as needed. The negative part 
of this is that when the older version of "foo" becomes obsolete and one 
of the newer versions becomes the canonical one, we've had to do a lot 
of swapping around, repo-copying, etc. in order to handle the situation. 
At best this is sub optimal, and at worse it causes pointless delays and 
confusion. It also causes pointless upgrades for users who already have 
"fooNN" installed when "fooNN" becomes just plain "foo." I'd
like to propose a different solution.

In situations where there are likely to continue to be a large number of 
"fooNN" versions, "foo-devel" versions, etc, I'd like to suggest that we 
actually encourage the use of "fooNN" ports, and then have "some 
mechanism" that points "foo" ports at the right version of "fooNN." One 
mechanism that could work (perhaps with minor adjustments) is the 
master/slave port idea. If the "foo" port is simply a slave to the 
proper "fooNN" port, then that makes it very easy to adjust the "link" 
when needed. I'm not sure if this model would solve all the problems I 
outlined, but it would be a good start I think. I'm sure that some of 
our ports geniuses could come up with better potential solutions.

What do y'all think?

Doug

-- 

     This .signature sanitized for your protection