"Failed to open portfile from registry" while reinstalling because of configure.optflags

René J.V. Bertin rjvbertin at gmail.com
Tue Oct 25 05:30:58 PDT 2016


I've been noticing "Failed to open portfile from registry" errors during certain operations like reinstalling (port -n upgrade --force). This turned out due in part to something I changed in one of my own portgroups, but after correcting that errors remained.

I've finally traced them down to my use of configure.optflags on the commandline, in order to pass in more than 1 compiler option. Curiously I have been doing this "for ages", and I have the impression that I did not get the error message. That may be incorrect: it can also be I simply didn't pay attention to them.

Anyway, after adding some debug output to relevant functions in "base" I see this when I reinstall port:bzip2 (doesn't use portgroups):

DEBUG: Uninstalling bzip2 1.0.6_0
DEBUG: Changing to port directory: /opt/local/var/macports/registry/portfiles/bzip2-1.0.6_0/7139f380a4b4965aac474caa6
DEBUG: workername=interp1 options=ports_nodeps yes configure.optflags {"-O3 -g"} ports_upgrade_force yes ports_ignore
_different yes ports_force yes ports_autoclean no subport bzip2
DEBUG: set option ports_nodeps to "yes"
DEBUG: set option configure.optflags to ""-O3 -g""
DEBUG: set option ports_upgrade_force to "yes"
DEBUG: set option ports_ignore_different to "yes"
DEBUG: set option ports_force to "yes"
DEBUG: set option ports_autoclean to "no"
DEBUG: set option subport to "bzip2"
Warning: Uninstall forced.  Proceeding despite dependencies.
DEBUG: Changing to port directory: /opt/local/var/macports/registry/portfiles/bzip2-1.0.6_0/7139f380a4b4965aac474caa689d42d0545960fe90e96ec50794eac2e1b2f4b5-2404
DEBUG: workername=interp2 options=configure.optflags {-O3 -g} ports_nodeps yes ports_ignore_different yes ports_upgrade_force yes ports_force yes subport bzip2 ports_autoclean no ports_nodepcheck yes
DEBUG: set option configure.optflags to "-O3 -g"
DEBUG: wrong # args: should be "set varName ?newValue?"
    while executing
"set user_options(configure.optflags) -O3 -g"
    invoked from within
"$workername eval set user_options($opt) $val"
    (procedure "macports::worker_init" line 123)
    invoked from within
"macports::worker_init $workername $portpath $porturl [macports::getportbuildpath $portpath] $options $variations"
    (procedure "mportopen" line 39)
    invoked from within
"mportopen file://${portfile_dir}/ [array get options_array] $variations"
    (procedure "mportopen_installed" line 28)
    invoked from within
"mportopen_installed [$port name] [$port version] [$port revision] [$port variants] $options"
Warning: Failed to open Portfile from registry for bzip2 @1.0.6_0 (wrong # args: should be "set varName ?newValue?"); registry=7139f380a4b4965aac474caa689d42d0545960fe90e96ec50794eac2e1b2f4b5-2404
--->  Deactivating bzip2 @1.0.6_0
DEBUG: deactivating file: /opt/local/share/man/man1/bzmore.1.gz

I deduce from this that a nested interpreter is invoked at some point, which causes the quotes on my configure.optflags value to get lost.

I don't think this can be due to anything I might have changed, but is there an easy way to figure out where that nested interpreter is called? My first guess would be the eval on the abovementioned line 123, but in that's evidently not the case (the "set option configure.optflags" DEBUG message is printed *before* that eval and already lacks the quotes). Printing a backtrace each time I print the workername= debug message could help.

Or maybe this is in fact something that's expected to happen?


More information about the macports-dev mailing list