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§ion=all
A similar story with FreeBSD, see:
http://www.freebsd.org/cgi/ports.cgi?query=vtk&stype=all
_______________________________________________
macports-users mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macports-users
