renaming vtk ports

[Joshua Root]

Darren Weber wrote:
> 
> I'm working on vtk ports this week, mainly vtk-devel.
> 
> Given prior discussion in the mailing list and ticket 19000
> http://trac.macports.org/ticket/19000
> 
> We've agreed to rename:
> 
> vtk -> vtk4 or vtk44  (I've created vtk44 in the svn trunk).
> vtk5 -> vtk
> vtk54 -> vtk-devel  (Done, in the svn trunk.)
> 
> The svn trunk currently contains (At revision 50417):
> vtk/
> vtk-devel/
> vtk44/
> vtk5/
> 
> With
> vtk @ 4.4.2
> vtk44 @ 4.4.2  (This is a copy of vtk, with an old version name)
> vtk5 @ 5.2.1
> vtk-devel @ 5.4.0  (Still working on this)
> 
> The next step to "renaming" the ports is to move vtk5 over to vtk and
> then remove vtk5, leaving
> 
> vtk44 @ 4.4.2
> vtk @ 5.2.1
> vtk-devel @ 5.4.0
> 
> What is the best way to proceed with this?  Maybe:
> 
> svn delete vtk
> svn rename vtk5 vtk
> 
> Apart from the practicality of to change the svn repository, what are
> the implications for the ports system?  I have nothing installed that
> depends on these ports, so 'port dependents vtk' will not show me
> anything interesting.  Is there a master dependency tree somewhere that
> can show what ports specify vtk as a library dependency (or is there an
> easy shell command to get this, using find to get all the Portfiles and
> grep or something to pull out lines with 'vtk' or something)?  If we can
> identify these dependencies, we can also change those Portfiles.

You can't just rename ports. Anyone who has the existing port installed
will never see it in the outdated list, so they'll never get the new one
unless they happen to discover it and install it manually. Additionally,
if you change dependents to depend on the new ports, there will be
conflicts with the old ports.

Rather than delete ports here, you need to leave them as stubs that tell
users to uninstall them and install the replacement. You can't even have
the stub depend on the new port, since dependencies are upgraded first
and the new port will conflict with the pre-stub version of the old one.

Unfortunately there is simply no way to make this "just work" at
present, so renaming ports is to be avoided whenever possible.

As for the svn mechanics, use svn mv whenever possible rather than
delete/add.

- Josh