Max Horn wrote: []
As a solution, I currently think of this setup: Add another splitoff FOO-common to FOO. Move all the common stuff there. Leave FOO itself mostly empty. Add "Depends: FOO-common" to the PMs, and add Depends on the PMs to FOO itself.
But doesn't the latter force you to build all the pms and their dependencies, including old perl-cores, at once?
I have no solution to offer, but I have a similar problem with the vtk-py package (complicated by the fact that for compatibility reasons there is an old "vtk" package, but this is an independent question). VTK is an enormous package that can take several hours to compile, and it contains among other bindings (tcl, C++, java) also python bindings. The python part is important, but it is only a fraction of the whole package which consists of binaries and libraries and lots of other things.
I have not yet found a really satisfactory solution. Right now I have py23 and py24 variants that mutually conflict/replace and have no splitoffs. There are two packages depending on vtk-pyXX, mayavi and ncvtk, and this can lead to problems if one of these depends on the py23 variant and the other on the py24 variant.
Somehow it seems to be natural to have the common parts in a common package and the pyXX parts in splitoffs, but I haven't found a solution that doesn't require the user to compile the whole thing at least twice, which I would rather avoid.
I am tending to a solution where I hide the whole package in varianted directories and give all binaries varianted names, so that they don't have to conflict, but this is a non-trivial porting problem, because the different parts have to find each other.
Another solution would be to drop variants completely and just dictate that for OSX 10.4 you have to use py24.
-- Martin ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 _______________________________________________ Fink-devel mailing list Fink-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/fink-devel
