The LOCALBASE on my systems is "/opt". Portupgade-ing failed today with: ===> Registering installation for glib-2.50.2,1 pkg-static: Unable to access file /home/ports/devel/glib20/work/stage/opt/share/gdb/auto-load/usr/local/lib/libglib-2.0.so.0.5000.2-gdb.py:No such file or directory pkg-static: Unable to access file /home/ports/devel/glib20/work/stage/opt/share/gdb/auto-load/usr/local/lib/libgobject-2.0.so.0.5000.2-gdb.py:No such file or directory *** Error code 74 I hand-edited the .PLIST.mktmp in glib20's ${WRKDIR} to replace "/usr/local" with "/opt" in the two lines affected and the port installed cleanly. Most other lines already had "/opt" properly -- only the above two were broken. Both options for this port -- COLLATION_FIX and DEBUG -- are off on this system.
Created attachment 181786 [details] [patch] fix for PREFIX != LOCALBASE I hit this, too. Just replacing /usr/local in pkg-plist with ${PREFIX} doesn't work because the ports infrastructure replaces %%PREFIX%% with %D and right now at least, the pkg tools don't seem to work with %D in the middle of a path name: pkg-static: Unable to access file /usr/ports/devel/glib20/work/usr/local/share/gdb/auto-load/%D/lib/libglib-2.0.so.0.5000.2-gdb.py:No such file or directory The attached patched uses a different SUB variable so the %D replacement doesn't happen. It works for now until the ports infrastructure &/or pkg is fixed to address the above issue.
pkg@ CC'd for comments.
I found this patch solved it for me, whether LOCALBASE or PREFIX is the better option I don't know. Index: pkg-plist =================================================================== --- pkg-plist (revision 440469) +++ pkg-plist (working copy) @@ -324,8 +324,8 @@ share/aclocal/glib-gettext.m4 share/aclocal/gsettings.m4 share/bash-completion/completions/gapplication -share/gdb/auto-load/usr/local/lib/libglib-2.0.so.%%LIBVERSION%%-gdb.py -share/gdb/auto-load/usr/local/lib/libgobject-2.0.so.%%LIBVERSION%%-gdb.py +share/gdb/auto-load%%LOCALBASE%%/lib/libglib-2.0.so.%%LIBVERSION%%-gdb.py +share/gdb/auto-load%%LOCALBASE%%/lib/libgobject-2.0.so.%%LIBVERSION%%-gdb.py share/gettext/its/gschema.its share/gettext/its/gschema.loc share/glib-2.0/codegen/__init__.py
(In reply to beldin from comment #3) Using %%LOCALBASE%% doesn't work if PREFIX != LOCALBASE (whether LOCALBASE is /usr/local or something else like /opt). root@j10-default:/usr/ports/devel/glib20 # make PREFIX=/foo stage package . . ===> Building package for glib-2.50.2_2,1 pkg-static: Unable to access file /wrkdirs/usr/ports/devel/glib20/work/stage/foo/share/gdb/auto-load/usr/local/lib/libglib-2.0.so.0.5000.2-gdb.py:No such file or directory pkg-static: Unable to access file /wrkdirs/usr/ports/devel/glib20/work/stage/foo/share/gdb/auto-load/usr/local/lib/libgobject-2.0.so.0.5000.2-gdb.py:No such file or directory *** Error code 1 That's why attachment 181786 [details] uses PREFIX.
(In reply to John Hein from comment #4) Gentlemen, once again: * LOCALBASE is where the port being built is to look for files installed by other ports, on which it depends. * PREFIX is where the port is to install its own files. beldin's change is not correct.
(In reply to Mikhail Teterin from comment #5) Indeed. Hence the patch.
A commit references this bug: Author: bdrewery Date: Mon May 22 19:07:16 UTC 2017 New revision: 441489 URL: https://svnweb.freebsd.org/changeset/ports/441489 Log: Fix build when PREFIX is not /usr/local. PR: 218659 Approved by: kwm Sponsored by: Dell EMC Isilon Differential Revision: https://reviews.freebsd.org/D10860 Changes: head/devel/glib20/pkg-plist
Thanks. I wasn't aware of the RESETPREFIX usage before this. Maybe that should be documented - I don't think I would have known what its intended use was from just the name, although my PLISTPREFIX isn't really any better in that regard. Is it's sole purpose in life to avoid having plist %D replacements?
(In reply to John Hein from comment #8) > Thanks. I wasn't aware of the RESETPREFIX usage before this. Maybe that > should be documented - I don't think I would have known what its intended > use was from just the name, although my PLISTPREFIX isn't really any better > in that regard. Is it's sole purpose in life to avoid having plist %D > replacements? Sorry I didn't see your PR before committing. RESETPREFIX is some kind of a hack for where %D doesn't work. In this case %D didn't work; it hit some bug in check-plist.