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 [[email protected]] Sent: 25 February 2015 15:13 To: Artur Szostak Cc: [email protected] Subject: Re: Order of activation/deactivation pre/post phases On Wed, Feb 25, 2015 at 8:54 AM, Artur Szostak <[email protected]> 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 /-| [email protected] pgp b2c9d448 _______________________________________________ macports-dev mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-dev
