2.3.0

[Clemens Lang]

Hi,

> However, I've noticed during my last use of port_cutleaves from contrib [1]
> that I see failures to open Portfiles from registry a lot more often than
> I used to.
> I tried investigating a little, but haven't been able to pinpoint a reason
> for that. […]
> 
> Can anybody reproduce this? It might not be a critical problem though,
> because it'd only break pre-/post-deactivate hooks, and we don't have a
> lot of those anyway.

I've seen this happen with debug output enabled now:

DEBUG: Executing org.macports.uninstall (gettext)
DEBUG: Changing to port directory: /opt/mports/var/macports/registry/portfiles/gettext-0.18.3.2_0/72c2558ef3fd1fb2daab1b5822e6a86e16af7bb3fb559eef213a28c352e493a4-3049
DEBUG: wrong # args: should be "set varName ?newValue?"
    while executing
"set user_options(_portgroup_search_dirs) /opt/mports/var/macports/registry/portgroups/7bbea60c69221b3e81858a4c11b6740a082d84fa11a3212e202f31720c7e1abc..."
    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}/ $options $variations"
    (procedure "mportopen_installed" line 26)
    invoked from within
"mportopen_installed [$port name] [$port version] [$port revision] [$port variants] $options"
Warning: Failed to open Portfile from registry for gettext @0.18.3.2_0
--->  Deactivating gettext @0.18.3.2_0

Can anyone make anything out of that?


I think we might actually want to hold off releasing 2.3 and have another
beta or at least an RC because there are a few things that came up in the
last few days:

Builds on Linux would probably fail because the in-tree copy of Tcl wouldn't
run because of a missing LD_LIBRARY_PATH in base/src/pkg_mkindex.sh.in. I've
added it for trunk in [1], but that hasn't been backported.

Meanwhile #43208 [2] (which only applies on trunk) uncovered that we don't
have a good way for contributed scripts that use the MacPorts API to find and
use the correct Tcl interpreter with the 2.3 release. I have added
  $prefix/bin/port-tclsh
to work around the first part of this problem. (Now that I think of it, maybe
a symlink would have been easier than a wrapper script and we might want to
change that.) However, all contrib scripts also source macports_fastload.tcl
from $prefix before loading the macports1.0 package and are still not
prefix-independent because of that. I thought about a couple of ways to work
around that, but given that macports_fastload.tcl is now pretty much useless,
I've thrown it out completely in a series of commits from r118559 to r118569.
I think it makes sense to backport those into 2.3 so we can deal with the
contrib scripts once and don't have to touch them again for 2.4.


Thoughts?

[1] http://trac.macports.org/changeset/118559/trunk/base/src/pkg_mkindex.sh.in
[2] https://trac.macports.org/ticket/43208
-- 
Clemens Lang