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
