qtcurve update failure

[René J.V. Bertin]

Marko Käning wrote on 20161213::06:29:51 re: "qtcurve update failure"

>Just got this:

>-->  Computing dependencies for qtcurve-extra
>--->  Activating qtcurve-extra @1.8.18_2
>Error: org.macports.activate for port qtcurve-extra returned: Image error: /opt/local/share/apps/color-schemes/QtCurveOSX.colors is being used by the active QtCurve port.  Please deactivate this port first, or use 'port -f activate qtcurve-extra' to force the activation.
>Please see the log file for port qtcurve-extra for details:

>There’s the overlap between the new qtcurve-extra and the old qtcurve…

Yes, the settings files used by all 3 "binary" subports were moved to a dedicated subport.

>Was easy to fix by uninstalling qtcurve.
>Yet it would have been nicer to recommend the uninstallation of a too old qtcurve in qtcurve-extra.

This is the kind of situation where you'd want to be able to print a warning at an appropriate time *before* the user starts the upgrade. Or you could halt the upgrade procedure at the opportune moment while the user takes the requested actions. Neither is possible currently.

@macports-devs: for future reference, is there way to automatise the deactivation of an old port? The perl (and p5*) ports are pretty smart during upgrades that I expected to cause this kind of trouble, but they can probably use the `replaced_by` feature, which isn't possible with QtCurve.

I can only think of deleting the files that are to be installed (if they already exist) in a pre-activate block, which should be safe but isn't very elegant.
I wonder if Debian's packaging scheme doesn't have a trick to indicate files which may already be installed by another package and can be overwritten safely if present.

R