pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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

The following reply was made to PR pkg/38651; it has been noted by GNATS.

From: Robert Elz <kre%munnari.OZ.AU@localhost>
Subject: Re: pkg/38651: libkver won't install in pkg_comp any more 
Date: Thu, 28 Aug 2008 18:52:27 +0700

 This is a multipart MIME message.
 Content-Type: text/plain; charset=us-ascii
 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 into
 /libkver/lib so its position is known, and LD_PRELOAD (or something)
 can be set in the environment so all commands run get 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....
 ps: when in the libkver/files/ you might alwo want to
 change the sequence of spaces in the LIBDIR assignment to tabs, the
 way they normally should be.
 Content-Type: text/plain ; name="Patch"; charset=us-ascii
 Content-Description: Patch
 Content-Disposition: attachment; filename="PATCH"
 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
 @@ -46,7 +47,14 @@
 +      ${MAKE} ${MAKEFLAGS}                                      \
 +              install
 +.if target(standalone-install)
  .include "../../mk/"
 Index: files/
 RCS file: /cvsroot/NetBSD/pkgsrc/pkgtools/libkver/files/,v
 retrieving revision 1.4
 diff -u -r1.4
 --- files/ 13 Dec 2003 17:45:59 -0000      1.4
 +++ files/ 28 Aug 2008 10:45:40 -0000
 @@ -2,7 +2,11 @@
  .if defined(PREFIX)
  # build from pkgsrc
 +LIBDIR=               ${STANDALONE_INSTALL}/lib
  LIBDIR=         ${PREFIX}/lib
  BINDIR=               ${PREFIX}/sbin
  MANDIR=               ${PREFIX}/man

Home | Main Index | Thread Index | Old Index