VTK port naming conventions

[Ryan Schmidt]

On Apr 14, 2009, at 19:27, Darren Weber wrote:

> The conclusion to be drawn from this part of our discussion is that  
> any ports that depend on a specific version of VTK can specify that  
> version dependency only if there is a version specific port  
> available (ie, vtkXY).  It is not possible for a port to specify a  
> dependency using the @X.Y.Z syntax.

That's right. You can only declare a dependency on a port, not on a  
specific version of a port or on a specific variant of a port. If you  
need a specific version or variant of a port you have to add code to  
the port to do that. See e.g. the pango port which checks for both a  
specific version and a specific variant of the cairo port.


> The next question is, why would any port require a dependency on a  
> specific version of VTK?  Furthermore, if it does, to what extent  
> is that port compatible with future releases of VTK?  So, moving on  
> to the next question below.

You'll have to ask someone who knows about vtk specifically. :) The  
developers of vtk could probably give recommendations for packaging  
it. They might have experience with how other distributions have  
packaged their software.


>> The only reason python and postgresql have separate ports for  
>> separate major versions is because the major versions are  
>> incompatible with one another. If you have a database that was  
>> created with postgresql 8.2, you cannot suddenly switch to 8.3;  
>> you must perform some database conversion which it is not  
>> MacPorts' place to do for you. Therefore we must let you switch at  
>> a time of your choosing and offer both versions. If you compile a  
>> module for python 2.5, you cannot use that module with python 2.6;  
>> it must be recompiled. Therefore we offer separate ports for each  
>> python port for use with each python version.
>>
>> Is this the case with vtk? If so, multiple ports are best. If not,  
>> a single port is best, for simplicity.
>
> I've taken some pain to read through the Apple doc on dynamic libs,  
> see:
> http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> DynamicLibraries/index.html
>
> It provides some useful tips on how to specify compatibility flags  
> for dynamic library builds.  That issue is something to take up at  
> the level of VTK development, rather than porting VTK (although  
> clearly there is a signficant relationship between the two).  I  
> have to do some more homework to be clear about this issue and how  
> the VTK build specifies compatibility (if it does so for OSX).

I don't think this is an issue you have to solve in the vtk port(s).  
As an example, we have only one port called gettext. When gettext was  
updated to a new version that was incompatible with the previous  
version, any port that used gettext had to be rebuilt. No, there is  
no mechanism in MacPorts for indicating that users would have to do  
this, nor a facility to help users do this. We just wrote it up in  
the hotlist with a script to fix it:

http://trac.macports.org/wiki/ 
ProblemHotlist#Aportfailedtobuildupgradeorrunwithamessagereferringtolibi 
ntl.3.dylib

It is one of this year's proposed Google Summer of Code projects to  
provide a mechanism for rebuilding any ports affected by such an  
upgrade:

http://trac.macports.org/wiki/SummerOfCode#rev-upgrade


> I have not had enough experience with VTK to know how compatible it  
> is across minor version releases.  To provide flexibility, I've  
> assumed that vtkXY should be sufficient to provide the major.minor  
> (X.Y) version specificity for any port that depends on VTK (ie,  
> I've not considered vtkXYZ to be necessary).  Certainly vtkX at a  
> minimum to provide the major release compatibility.
>
> At this point, do we have a consensus that port names should have a  
> version string in the name?  (We may not agree on the specificity  
> of that version string - vtkX, vtkXY, vtkXYZ - but it appears the @  
> syntax is not an option.)

A number should only be used in the port name if you need to have  
multiple ports that install multiple different versions of the  
software. For most ports, this should not be necessary; just provide  
a single port with the latest version of the software.

To know how this should be handled for vtk, you need to answer the  
question: why would a user install the old version if a new version  
is available? Why would a user install vtk 4.4.2 if 5.2.1 is  
available? Why would a user install vtk 5.2.1 if 5.4 is available? If  
there is no reason why a user would do this, then multiple ports are  
not needed.


> Any thoughts about additional naming conventions, as used in Debian  
> and FreeBSD?  That is, should we stick with variants (with some of  
> the issues that have come up recently in vtk5, see ticket http:// 
> trac.macports.org/ticket/19111). Bear in mind that variants cannot  
> be specified as dependencies (correct me if that is wrong OR if  
> that will change in a new release of port).

At 6 and a half years old, it is one of the oldest tickets we have:

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

I do not expect it to be resolved soon. I'm not even convinced it  
should be resolved. Then again, it is on this year's list of  
potential Google Summer of Code projects to rewrite the dependency  
engine which could resolve this issue:

http://trac.macports.org/wiki/SummerOfCode#dependencies

> What about:
>
> libvtk[XYZ] ?  (where [XYZ] is some variant specificity to be decided)

You mean some version specificity?

> vtk[XYZ]-data ?
> vtk[XYZ]-pythonX.Y ?
> vtk[XYZ]-qtX ?
>
> etc?

I would prefer no dot in the python version number, so e.g. vtk- 
python26 not vtk-python2.6. This would be consistent with the  
existing names of the python ports (python26) and their modules (py26- 
foo). I'm not certain why perl5.8 got a dot in its port name. I'd  
rather it didn't, but since we don't have a facility to rename ports  
cleanly, we'll just leave it as is.

The determination of whether you can make separate ports for these  
options is somewhat dependent on the build process employed by the  
software in question. If (pulling numbers entirely out of the air) it  
takes 4 hours to build vtk without python support and 5 hours to  
build it with python support, you would want a hypothetical vtk- 
python26 port to be able to build in 1 hour, not 5 hours. Then again,  
if the build times are 4 and 5 minutes, then it doesn't matter so  
much. Maybe build time also isn't the biggest priority.

> For reference, again, see the Debian distribution, eg:
> http://packages.debian.org/search? 
> keywords=vtk&searchon=names&suite=stable&section=all
> A similar story with FreeBSD, see:
> http://www.freebsd.org/cgi/ports.cgi?query=vtk&stype=all