Re: pkg/38651: libkver won't install in pkg_comp any more

[Robert Elz <kre%munnari.OZ.AU@localhost>]

Since nothing has happened with this PR since I sent it in mid May,
and as the bug has meant I have been unable to build any packages
since then (my last successful update was early April, for a while
after that I had no time for package updates), I thought I really
should go find a fix that would (at least) work for me, and which
just might motivate someone who really knows what they are doing
with this stuff (which is certainly not I) to find a proper fix.

The "unable to build" in the previous paragraph is because I only
build packages using pkg_comp and libkver these days, aside perhaps
from he bulk build framework (which does way more than I need)
it is the only rational way to build & update packages (without
having a throw away system where what's actually installed is
irrelevant - pkg_comp more or less provides that environment).

I build with NetBSD 3.0 sets (libkver emulating NetBSD 3.0), so the
binary packages I create will work on any of the NetBSD systems I
care about (no longer running anything older).  I need libkver to
make that happen, as my build system is a 4.0 (and a bit) system now.

To recap the problem ... pkg_comp wants to install libkver.so into
/libkver/lib so its position is known, and LD_PRELOAD (or something)
can be set in the environment so all commands run get libkver.so linked
into them (which then makes uname output claim the system version is 3.0,
or however it is set).

libkver supported that by providing a standalone-install: target that
installed into that fixed location.  It used to do that by simply setting
PREFIX to /libkver when building libkver for this standalone-install.

Until sometime in April (or maybe very early May) this year, that worked
fine - neither libkver nor pkg_comp have been changed (in any way) since
well before then.   But something in pkgsrc evidently changed, and that
method of doing an install into a very non-standard place stopped working.

Instead, what happened was that pkginstall (pkg_add etc) got installed
into /libkver/* (because NetBSD 3.0's pkgtools are too old for pkgsrc
these days, and as /libkver was empty (non-existing) and PREFIX was
set to that, there was no other possible version, so a new one was made
and installed, after that, libkver just vanished somewhere (I never found
where it went, I did a find in the pkg_comp sandbox, and there was no
mention of it anywhere).   Still, LD_PRELOAD was set to use it, so every
command after it should have been installed simply failed to run.

I append a patch below that alters the way libkver does the standalone-install
(I think it should make no material difference to a "noemal" install of
libkver, though I'm not sure why anyone would ever want one of those).

A couple of notes...

I set PKGREVISION - for a NetBSD package (with the entr\ire source in
pkgsrc) that's really silly, you'd normally expect the rev number to
just get bumped, but I'll leave that for someone else.  libkver has been
(aside from this) stable fo so long now it should probably be promoted
to version 1.0 or something, rather than just 0.7 or 0.6.1 (or 0.6nb1).

I have CHECK_FILES forced to "no" in the standalone-install case - that's
because the PLIST doesn't anticipate the lib files being yanked out of
${PREFIX}/lib and installed elsewhere and complains - since this is
(where it matters to me anyway) using pkg_comp, and pkg_comp always sets
PKG_DEVELOPER=yes the check-files test is normally defaulted to yes, and
building aborts when t fails.  The no setting doesn't eliminate all of the
poblems with the PLIST not matching what gets installed, but it reduces what's
left to noise (when built this way no binary package gets created, and
what is installed is installed well enough to work correctly, so the
problems don't matter - as long as it works, no-one really cares what
is in the pkg_comp arena - pkg_deleting this standalone libkver would be
fatal to pkg_comp - just like when it couldn't install, deleting it is
done by removing, and recoreating, the entire sandbox).

This is all truly ugly, but here is the patch that worked for me.
Someone, please, do something to either pkgsrc, or libkver, so
this setup goes back to working properly again....

kre

ps: when in the libkver/files/Makefile.inc you might alwo want to
change the sequence of spaces in the LIBDIR assignment to tabs, the
way they normally should be.


Index: Makefile
===================================================================
RCS file: /cvsroot/NetBSD/pkgsrc/pkgtools/libkver/Makefile,v
retrieving revision 1.28
diff -u -r1.28 Makefile
--- Makefile    12 Apr 2008 22:43:09 -0000      1.28
+++ Makefile    28 Aug 2008 10:51:38 -0000
@@ -4,6 +4,7 @@
 CATEGORIES=            pkgtools
 MASTER_SITES=          # empty
 DISTFILES=             # empty
+PKGREVISION=           1
 
 MAINTAINER=    seb%NetBSD.org@localhost
 #HOMEPAGE=
@@ -46,7 +47,14 @@
 
 LIBKVER_STANDALONE_PREFIX?=    /libkver
 standalone-install:
-       ${MAKE} ${MAKEFLAGS} PKG_DBDIR=${LIBKVER_STANDALONE_PREFIX:Q}/pkg \
-         PREFIX=${LIBKVER_STANDALONE_PREFIX:Q} install
+       ${MAKE} ${MAKEFLAGS}                                      \
+               STANDALONE_INSTALL=${LIBKVER_STANDALONE_PREFIX:Q} \
+               install
+
+.if target(standalone-install)
+CHECK_FILES=   no
+pre-install:
+       ${MKDIR} ${STANDALONE_INSTALL}/lib
+.endif
 
 .include "../../mk/bsd.pkg.mk"
Index: files/Makefile.inc
===================================================================
RCS file: /cvsroot/NetBSD/pkgsrc/pkgtools/libkver/files/Makefile.inc,v
retrieving revision 1.4
diff -u -r1.4 Makefile.inc
--- files/Makefile.inc  13 Dec 2003 17:45:59 -0000      1.4
+++ files/Makefile.inc  28 Aug 2008 10:45:40 -0000
@@ -2,7 +2,11 @@
 
 .if defined(PREFIX)
 # build from pkgsrc
+.if defined(STANDALONE_INSTALL)
+LIBDIR=                ${STANDALONE_INSTALL}/lib
+.else
 LIBDIR=         ${PREFIX}/lib
+.endif
 BINDIR=                ${PREFIX}/sbin
 MANDIR=                ${PREFIX}/man
 .else