Projects with multiple versions in our ports tree
DougB at FreeBSD.org
Wed Aug 11 17:43:50 PDT 2004
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?
This .signature sanitized for your protection
More information about the freebsd-ports