questions regarding selfupdate issue

Clemens Lang cal at macports.org
Sat Nov 15 03:59:57 PST 2014


Hi René,

----- On 15 Nov, 2014, at 01:13, René J.V. Bertin rjvbertin at gmail.com wrote:

> I did run with the prefix set to the actual location for some time (and
> /opt/local just an easy entry point for my own convenience). I don't remember
> if these errors started after that, but they probably did.

The changed prefix should not have caused this. ${prefix} doesn't play a large
role in the conversion that apparently failed other than that it must point to
the right directory (which it did if you symlinked it).


> The weird thing is that I also get them on my 10.9 installation, and that one
> has been rebuilt from scratch following the migration guidelines.

The same problem where the Portfile content is being used as filename?


> Annoying that there's the akonadi output in the middle of things, but it *does*
> look like something tries to take the contents of a Portfile and use that as a
> file name. Any idea how and where that might arrive?

Yes, that's exactly what happens – it happens because we changed the purpose of
a database field, which used to store the contents of the Portfile, but now
stores the filename of a file with the Portfile contents below
  /opt/local/var/macports/registry/portfiles/${name}-${version}_${revision}/.
The code was changed to use this field as filename, and the database schema was
updated using the code in [1] to create a new portgroup table and set a marker
bit called portfiles_update_needed in the metadata table, which tells MacPorts
that the field has been re-purposed and a conversion still needs to be done.

The conversion is done by [2], which is called when you run "make install" in
a MacPorts source tree (which is what selfupdate does) or when you update using
the MacPorts installer. It also transparently handles the database upgrade,
because that is implicit as soon as the database is opened with the new codebase.

I don't know why this did not work for you, and I don't know whether it's safe to
run dedup_portfiles.tcl again now to attempt to fix the problem – you'll have to
look at your database yourself to figure it out. I have no idea how you managed to
get updated MacPorts *code* installed on your system without also triggering the
appropriate update *scripts*.


[1] http://trac.macports.org/browser/branches/release_2_3/base/src/cregistry/sql.c?marks=333-360#L330
[2] http://trac.macports.org/browser/branches/release_2_3/base/src/dedup_portfiles.tcl.in
-- 
Clemens Lang


More information about the macports-users mailing list