Re: [Fink-devel] Common splitoff for a package with variants

[Martin C. <cos...@wa...>]

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