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 [email protected]
port install [email protected]
Furthermore, it should be possible to do this:
port install [email protected]
port build [email protected]
port deactivate [email protected]
port activate [email protected]
... 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 [email protected]" 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.
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
