qtcurve update failure

[Mojca Miklavec]

On 13 December 2016 at 11:45, René J.V. Bertin wrote:
> On Tuesday December 13 2016 11:22:09 Mojca Miklavec wrote:
>
>>So:
>>- you have an old qtcurve installed
>>- the new qtcurve will have a new runtime dependency qtcurve-extra
>>- qtcurve-extra doesn't depend on qtcurve, but fails to activate if
>>qtcurve is already installed?
>>
>>Or did I misunderstand something?
>
> No, that's correct.
>
>>
> >From what I understand this is exactly the case where you would want
>>to use the deactivate hack. You would expect users to run
> [..]
>
> Yes, indeed. The only question I have is how the upgrade process handles variants. Suppose the user has the old qtcurve installed with +qtonly. Will that variant be preserved when the actual qtcurve upgrade starts, even if qtcurve is deactivated and regardless of how many versions/variants are installed? Even if it does it'll still be a bit brittle in case anything unforeseen goes wrong during the qtcurve-extra install.

If something goes wrong during the build, it won't deactivate the old
port. It would only be a "problem" if there would be an additional
error during activation of qtcurve-extra. And even then one could
always activate the old port again.

> It'd be a bit complicated to test this on my end now.

I don't know either, but you can test with ports "foo" and "bar" that
don't do anything other than echo a string with installed variants to
a single file.

> And supposing this is issue is moot, should I still add the hack, or can we do as Marko suggested?

Of course you can ask users to manually uninstall the port, but
they'll loose variants for sure if they just call deactivate/uninstall
& install :) And if they uninstall the port (and something breaks),
they won't be able to activate it again.

The hack sounds better to me, but it's eventually your choice.
Maintainer will be the one that will have to handle all tickets on
Trac :)

Mojca