On Sep 6, 2017, at 05:10, Rainer Müller wrote:

> On 2017-09-06 09:52, Ryan Schmidt wrote:
>> When the ssh-copy-id files were removed from the openssh port [1] and the 
>> port was thus made to no longer conflict with the ssh-copy-id port, the 
>> ssh-copy-id port would install, but could not be activated if the prior 
>> version of openssh was installed, as would be the case during an upgrade 
>> [2]. This version of ssh-copy-id did build and install and activate 
>> successfully on the buildbot workers (since they did not have openssh active 
>> at the time) and is being distributed by our packages server.
> 
> Uh, of course. Sorry, I missed this when merging the change.
> 
>> The deactivate hack was added to the port [3], but because its revision was 
>> not increased, my understanding was that my machine would still complain 
>> that ssh-copy-id could not be activated because openssh was active, because 
>> the pre-activate block added in [3] would not be used, because MacPorts 
>> would look at the version of the Portfile that was already stored in the 
>> registry with the installed copy of the port, not the version of the 
>> Portfile in the ports tree. And yet, the upgrade now works for me.
>> 
>> I was sure that activate and deactivate phases were run from a copy of the 
>> Portfile kept in the registry, since the activate and deactivate phases of 
>> the current version of the Portfile in the ports tree wouldn't necessarily 
>> be compatible with whatever probably older version of the port the user had 
>> installed. And yet, if I add 'ui_msg "hello"' to the pre-activate block of 
>> the Portfile, and then tell MacPorts to install a binary from our server 
>> which doesn't contain that message, I still get:
>> 
>> $ sudo port -b install ssh-copy-id
>> --->  Fetching archive for ssh-copy-id
>> --->  Attempting to fetch ssh-copy-id-7.5p1_1.darwin_16.noarch.tbz2 from 
>> https://packages.macports.org/ssh-copy-id
>> --->  Attempting to fetch ssh-copy-id-7.5p1_1.darwin_16.noarch.tbz2.rmd160 
>> from https://packages.macports.org/ssh-copy-id
>> --->  Installing ssh-copy-id @7.5p1_1
>> hello
>> --->  Deactivating openssh @7.3p1_0+kerberos5+universal+xauth
>> --->  Activating ssh-copy-id @7.5p1_1
>> --->  Cleaning ssh-copy-id
> 'port install' always works with the Portfile from the ports tree and
> executes port targets on that, while 'port de/activate' will use the
> Portfile stored in the registry.
> 
> Internally, 'port install' is actually running the activate target,
> which requires the install target to run before. The install target will
> invoke archivefetch and if that can download a binary archive, all
> targets up to including destroot are skipped.
> 
> Note that then MacPorts will also store the Portfile from the ports tree
> in the registry, as that was used to install this port. The Portfile
> from the binary archive is never used.
> 
> Binary archives were designed to spare users the expensive build targets
> up to destroot. The ports tree will still be used and the ports tree is
> not only a package index.
> 
> [There is one exception, though, which is that the +PORTFILE in the
> archive would be used if you gave port only the binary archive to
> install. This is quite uncommon, but the only use of that file.]

I still don't understand why I was able to upgrade my ports without an 
activation failure, when the deactivate hack was added to ssh-copy-id without a 
revbump.

At what point does the Portfile from the ports tree get put into the registry? 
Is it at "install" time or at "activate" time? I thought it was at "install".

When a port is activated, does MacPorts look for pre-activate and post-activate 
blocks in the Portfile in the ports tree, or in the Portfile in the registry? I 
thought it looked in the registry.


Reply via email to