trying to understand the --no-exec activate option (on by default?)

[René J.V. Bertin]

Hi,

I'm trying to understand how/where the activate --no-exec option is set, I have the impression it's on by default.

For instance, I have a port that implements the following approximation of a "strongly suggested runtime dependency":

```
# we cannot use depends_run because of circular dependencies so we can
# only emit a warning if we don't detect kf5-kdevelop-clang-parser as active
# in the post-activate. This warning will always print at least once...
post-activate {
if {[catch {set installed [lindex [registry_active ${name}-${PARSER}] 0]}]} {
ui_warn "Please remember to install (or activate) port:${name}-${PARSER}"
}
}
```

That warning only prints during an install or upgrade (when the runtime dep is not active).

The default for this option should be OFF IMHO; there are also ports which do important things in the post-activate; the lldb ports remind the user that an executable needs to be code-signed for instance. Evidently this has to be done each time the port is (re)activated.

R.

[Vincent Habchi]

Post by René J.V. Bertin
That warning only prints during an install or upgrade (when the runtime dep is not active).
The default for this option should be OFF IMHO; there are also ports which do important things in the post-activate; the lldb ports remind the user that an executable needs to be code-signed for instance. Evidently this has to be done each time the port is (re)activated.

Why not use the “note” keyword for that? Just wondering (hoping that makes sense)

Vincent

[René J.V. Bertin]

Post by Vincent Habchi
Why not use the “note” keyword for that? Just wondering (hoping that makes sense)

Because then you'd get the warning every time, even if the runtime dependency is available.

But in fact, I'm not certain notes are printed when you (re)activate a port. And for them (notes) I kind of agree with the principle of only showing them when you install or upgrade a port.

R.

[Rainer Müller]

Post by René J.V. Bertin
I'm trying to understand how/where the activate --no-exec option is set, I have the impression it's on by default.

To clarify the double negative here, the post-activate phase will be
executed by default.

Rainer

[René J.V. Bertin]

Post by Rainer Müller
To clarify the double negative here, the post-activate phase will be
executed by default.

That's what I understand from the embedded help but also what I'm trying to confirm in the code.
As said, I'm not seeing output from post-activate phases when I reactivate a port after having deactivated it.

From what I understand the default is that the corresponding option variable ("ports_activate_no-exec") isn't even defined. It's unclear to me what the other 2 expressions check for in that same if in proc action_activate; maybe they're the reason my post-activate phases aren't executed after each activation?

[Rainer Müller]

Post by René J.V. Bertin
That's what I understand from the embedded help but also what I'm trying to confirm in the code.
As said, I'm not seeing output from post-activate phases when I reactivate a port after having deactivated it.

Have you tried unconditional output first? Works fine for me here.

Post by René J.V. Bertin
From what I understand the default is that the corresponding option variable ("ports_activate_no-exec") isn't even defined. It's unclear to me what the other 2 expressions check for in that same if in proc action_activate; maybe they're the reason my post-activate phases aren't executed after each activation?

Correct, these variables will only be defined when the argument is given
on the command line. The code that sets ports_${action}_${key} is in
proc parse_options in port/port.tcl.

Not sure which expressions you mean, but the call to registry::installed
is used to verify that the given portname/version combination is
actually available in the registry.

Rainer

[Fred Wright]

Post by René J.V. Bertin
The default for this option should be OFF IMHO; there are also ports
which do important things in the post-activate; the lldb ports remind
the user that an executable needs to be code-signed for instance.
Evidently this has to be done each time the port is (re)activated.

In the particular case of code signing, would it be possible to do that in
the post-destroot phase, so that the signature would remain across
activations and deactivations, or does the signature mechanism defend
against that (even though a verbatim copy of signed code should still be
signed)?

Fred Wright

[Rainer Müller]

Post by Fred Wright
In the particular case of code signing, would it be possible to do that
in the post-destroot phase, so that the signature would remain across
activations and deactivations, or does the signature mechanism defend
against that (even though a verbatim copy of signed code should still be
signed)?

No, it cannot be done in the destroot, as that are the files that will
be put into an archive for redistribution. Whatever signing identity you
are using might not be valid everywhere.

We had a lengthy thread about code signing quite a while ago with a few
different proposals:
https://lists.macports.org/pipermail/macports-dev/2016-September/033518.html

Rainer