Order of activation/deactivation pre/post phases

[Artur Szostak]

OK, so as I suspected, activation performs the dependency check and triggers a deactivation of the older port.
Not knowing much about the internals of MacPorts, my assumption would have been that all, pre-<phase>, <phase>, pos-<phase> groups happen atomically as a transaction. But apparently that is not the way the Portfile API works. Might be good for someone to mention that in the documentation at some point.

But now for the problem that triggered this question:
I want a Portfile to download a large amount of demo data. A few Gbytes worth. I dont want to destroot it because then the binary packages become huge and unmanageable. The demo data need only be present when the port is active. Not knowing the correct way to overload the activate and deactivate phases in a Portfile. My solution was to place the download and cleanup in the pre-activate and post-deactivate hooks. The reason for pre-activate and not post-activate is that I noticed that the port would get marked as all OK, even if the demo data did not download and unpack correctly. i.e. post-activate is already too late, the port has been fully registered at that point.
This port works fine up to the point that one tries to upgrade it to a newer version. At which point the demo data is missing after an upgrade because of the order that the hooks are called.

Is there an easy and correct way to overload the activate/deactivate phase itself? That should solve this problem.

Any better ideas are welcome.

Kind regards.

Artur

________________________________________
From: Arno Hautala [arno at alum.wpi.edu]
Sent: 25 February 2015 15:13
To: Artur Szostak
Cc: macports-dev at lists.macosforge.org
Subject: Re: Order of activation/deactivation pre/post phases

On Wed, Feb 25, 2015 at 8:54 AM, Artur Szostak <aszostak at partner.eso.org> wrote:
>
> Why does a pre-activate phase happen before a deactivation phase when upgrading from an older port revision to a newer one?

My assumption is that deactivating v1 is a requirement (dependency /
prerequisite) of activating v2, so it  occurs before that step. Your
proposed order would make deactivating v1 a prerequisite of the
pre-activate phase of v2.

This is the sort of thing where I can see arguments for both
behaviors, but in the end it's going to be a wash.

Is there a specific goal you're trying to achieve that can't be solved
by conforming to how things are done now? Can you explicitly call
deactivate from pre-activate?

--
arno  s  hautala    /-|   arno at alum.wpi.edu

pgp b2c9d448