Case in point for wxWidgets split.

[Kuba Ober]

I'll demonstrate with a specific case what I intend to do with wxWidgets.

fityk, a nice (because it's Polish, duh) curve fitting tool, supports wxWidgets 2.8 up to 0.9.8.
From 1.0.0 onwards, it needs wxWidgets >= 2.9.1.

Here's what I want to do, illustrated with this case:

1. wxWidgets28 is the renamed current wxWidgets port, and tracks 2.8 wxWidgets releases.
Note that this port won't have "replaces wxWidgets" in it!
2. wxWidgets is the renamed current wxWidgets-devel port, and tracks 2.9 releases
This port will be marked "replaces wxWidgets-devel". wxWidgets-devel will come back for 2.10
or 3.0, and then the wxWidgets port will have to stop replacing wxWidgets-devel, of course.

3. fityk is renamed to fityk0 and made dependent on wxWidgets28; no functionality is changed
4. fityk0 is upgraded to 0.9.8 (latest version that supported wxWidgets 2.8)
5. fityk is a new port that tracks current fityk releases and depends on wxWidgets

Existing users will see a seamless upgrade to the most recent wxWidgets and most recent fityk.
*NEW* Users on Tiger need to manually install compatible fityk0, and that will automatically
pull in wxWidgets28. This is IMHO a minor inconvenience.

A single commit will have to implement #1 and #3, so that nothing gets broken by partial updates,
even though I will of course submit it in separate patches.

There's 17 ports that depend on current 2.8 wxWidgets, and 3 ports that depend on wxWidgets-devel.

So #1 will be one patch and #3 will be 17 patches, all of them to relevant Portfiles, and will have
to be applied in a single commit.

For the 3 ports that depend on wxWidgets-devel, there will be one new Portfile and 3 patches to
existing portfiles -- again, to be applied in a single commit.

I'd like a go ahead before I start working on this. Please comment on this plan! It's important
to move ahead, IMHO, to stop having dirty per-port hacks that detect xcode versions and other jazz
like that. That's what was recently planned for pgAdmin3 and would have been a mess, since pgAdmin3
is not the only port in such a predicament!

Cheers, Kuba