VTK port naming conventions

[Ryan Schmidt]

This is really more of a development question and not a usage  
question so macports-dev may be a better place to continue this.


On Apr 14, 2009, at 12:55, Darren Weber wrote:

> I agree with Ryan, that separate ports provide more clarity for  
> dependency specifications, but I do not understand macports  
> variants very well.  For instance, there is a track ticket on VTK  
> with some discussion about this issue, see:
> http://trac.macports.org/ticket/19000
>
> In that ticket, tgamblin raises the possibility of using the @X.Y.Z  
> syntax to get version specific installs, eg:
> port install vtk at 5.2.1
> port install vtk at 5.4.0
> Furthermore, it should be possible to do this:
> port install vtk at 5.2.1
> port build vtk at 5.4.0
> port deactivate vtk at 5.2.1
> port activate vtk at 5.4.0
> ... etc
> If so, does this automatically resolve @X.Y into the latest Z  
> version available?  Also, similarly, does it automatically resolve  
> @X into the latest Y.Z version?  In my experience with macports to  
> date, the @ syntax must be very specific to be effective, it  
> doesn't have automatic resolution to the latest version.  I know  
> that Debian has some "symbolic" package names that are resolved to  
> the latest version of a package (an auto-update package name).

MacPorts does not offer the facility to install a specific version of  
a port. It only lets you install the current version of the port.

"port install vtk at 5.2.1" will not install version 5.2.1; it will  
install whatever version is currently offered by the port. Once a  
port has been updated to a new version, MacPorts no longer has any  
information about the older version of the port.

You can *uninstall*, *deactivate* and *activate* specific versions  
which have already been installed. For example, if you install zlib,  
and that gives you version 1.2.1, and later version 1.2.3 becomes  
available and you "port upgrade zlib" to get it, you now have two  
versions of zlib installed: zlib @1.2.1_0 and zlib @1.2.3_0, with the  
latter being active. If you wish to go back to 1.2.1_0, you can "port  
deactivate zlib" (which will deactivate zlib @1.2.3_0; specifying the  
version is not necessary here because there is only one zlib active)  
and then "port activate zlib @1.2.1_0". Note this is only possible  
because the old version had already previously been installed.

Instructions for installing an older version of a port directly are  
in the wiki:

http://trac.macports.org/wiki/howto/InstallingOlderPort


> In any case, there are some issues with simultaneous version  
> installations (please see the trac ticket comments for some  
> details).  Given some differences of opinion, it would be great to  
> work out a consensus on how best to move forward.  This requires  
> broader discussion that a track ticket, as the resolution is not  
> necessarily specific to any particular port, although this  
> discussion has a focus on VTK for example.
>
> Any ports that depend on a specific version of vtk should be able to:
> (a) specify a dependency on a "vtkXY" port name that includes at  
> least an XY version (or use the @X.Y.Z syntax?),
> and
> (b) restrict the build and link search paths to the version required.
>
> To my knowlege, vtk doesn't provide a utility like /opt/local/lib/ 
> postgresql83/bin/pg_config, but cmake does have some macros for  
> searching out include and library paths (this may also apply to  
> ports in the K-desktop, as they have adopted cmake as their build  
> tool).  In the cmake search paths, there are several variables that  
> control the search, including:
>
> CMAKE_FIND_FRAMEWORK
> CMAKE_FIND_ROOT_PATH
> ONLY_CMAKE_FIND_ROOT_PATH
> NO_CMAKE_SYSTEM_PATH
> NO_CMAKE_ENVIRONMENT_PATH
> NO_SYSTEM_ENVIRONMENT_PATH
> CMAKE_FRAMEWORK_PATH
> CMAKE_APPBUNDLE_PATH
> CMAKE_INCLUDE_PATH
> CMAKE_INCLUDE_DIRECTORIES_BEFORE
>
> Given there are relatively few ports that depend on VTK, I've been  
> looking for inspiration from more significant libraries, like  
> postgresql and python.
>
> A possible solution is to adopt a model something like  
> postgresql8x, where the installation goes almost entirely into /opt/ 
> local/lib/postgresql8x, including /opt/local/lib/postgresql83/bin,  
> for instance.  Translating that model to vtk might result in  
> something like:
> /opt/local/include/vtk-X.Y
> /opt/local/lib/vtkX.Y
> These paths are already the defaults, given $prefix = /opt/local,  
> but notice how posgresql83 has something like a bin path within the  
> lib path, eg:
> /opt/local/lib/vtk-X.Y/bin
> This would separate any vtk binaries that are version specific,  
> rather than have them clash under /opt/local/bin/.
>
> Another possible solution is to adopt a pythonX.Y model, where the  
> version specific installs include a version suffix.  In addition,  
> there is the utility python_select to define the 'current'  
> version.  In this model, a build that depends on a specific version  
> of VTK might "temporarily" use something like python_select to  
> define the current version for the build.

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.