Case in point for wxWidgets split.

[Titus von Boxberg]

Am 21.09.2012 21:48, schrieb 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!

As already pointed out by Mojca:
Pulling the suffixless wxWidgets port to 2.9 is a good idea.
Splitting ports that do support wx > 2.9 just to have a working
version on Tiger is no good because you're bloating macports
with ancient ports that almost noone will use.

The more important cases are ports that don't support wx 2.9.

Thus, I think that you should start with such a port.
Afaik pgadmin is such a port.

Then, how would you resolve the
"conflicts       wxgtk wxWidgets28"
in the new 2.9 wxWidgets<nosuffix> port (quote already updated by me)?

Regards
Titus