Variants vs. new ports for different version

[Ryan Schmidt]

On May 28, 2008, at 10:22, Frank Schima wrote:

> What's the best practice for handling ports with different versions?
>
> For example, take tcl/tk <http://www.tcl.tk/software/tcltk/>.
> Currently it is up to version 8.5.2 and the port files for tcl and tk
> are both using that. However, the 8.4 tree is also still updated.
> MacPorts does not support the 8.4.x versions. But blt, for one,
> conflicts with tcl/tk 8.5.2 and needs 8.4.x to be used.
>
> I was planning to add support for tcl and tk 8.4.19. Is it alright to
> just add a variant on the ports for the 8.4.x version? Obviously the
> other way is to create new tcl84 and tk84 Portfiles.
>
> The advantage to using a variant is that there are more than one other
> ports that depend on tcl/tk and so they, in theory, would not need to
> be changed. However, in the case of blt, it would need to depend on
> the 8.4.x variant of tcl and tk. It's not clear to me from reading the
> wiki if it's possible to depend on a specific variant. Can someone
> kindly explain if that's possible?
>
> Furthermore, it appears that it is not possible to install both 8.5.x
> and 8.4.x versions of tcl and tk at the same time. So only one should
> be allowed.
>
> Are there other ports like this and what has been done?

It's not ok for a port variant to change the version of software that  
is installed. I'm not sure where that's documented but it was told to  
me once.

Also it's not possible for a port to depend on a specific variant of  
another port; see:

http://trac.macports.org/ticket/126

I think the way we do it is to just upgrade ports when new versions  
are out. If it's later discovered that a particular other port  
doesn't work with the updated version, then at that point a new port  
for the older version can be created from an older version in the  
repository.

For example, if blt does not work with tcl/tk 8.5.x and cannot be  
made to work with that version, then you can now create new ports  
tcl84/tk84 from the last version of the tcl/tk ports that used  
version 8.4.x. Like this:

svn checkout -N http://svn.macports.org/repository/macports/trunk/ 
dports/
cd dports
svn up -N lang x11
svn up lang/tcl x11/tk
svn cp -r 32234 lang/tcl lang/tcl84
svn cp -r 32234 x11/tk x11/tk84

Now fix the "name" field in lang/tcl84/Portfile and x11/tk84/ 
Portfile. Since this would be your baby, you should add yourself to  
the maintainers line. You should stay in contact with the existing  
maintainer to ensure that changes he makes to tcl/tk can also be  
applied to tcl84/tk84.

You would also have to modify these new tcl84/tk84 ports so that they  
install into different places than the tcl/tk ports, so that it is  
possible to install both tcl and tcl84 (and tk and tk84) at the same  
time. Then:

svn ci -m "tcl84, tk84: new ports based on r32234 of tcl and tk"

Then you change blt so it depends on tcl84/tk84 and can find the  
tcl84/tk84 software wherever it got installed (since it had to be  
modified to install in a nonstandard location to allow simultaneous  
installation with the newer version).


Precedent for this is the apache20 port (and the accompanying apr0  
and apr-util0 ports), which were created after the apache2 port got  
updated to version 2.2 (and apr and apr-util were updated to 1.2)  
which was incompatible with something.


I should point out though that it's preferable to work with the  
developers of blt to get it to work with tcl/tk 8.5 and not create  
new tcl84/tk84 ports. Better to move forward than backward. For  
example graphviz 2.16 didn't work with tcl/tk 8.5. I could have  
created tcl84/tk84 ports then, but instead I reported the problem to  
the developers of graphviz and disabled tcl/tk support in the  
graphviz port until they released version 2.18 which does support tcl/ 
tk 8.5. See:

http://trac.macports.org/ticket/13813