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>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: pkg/38651 (libkver won't install in pkg_comp any more)
Date: Sat, 13 Mar 2010 11:00:55 +0700

     Date:        Fri, 12 Mar 2010 13:58:13 +0000 (UTC)
     From:        jmmv%NetBSD.org@localhost
     Message-ID:  <20100312135813.0CA1763B11D%www.NetBSD.org@localhost>
 
   | Synopsis: libkver won't install in pkg_comp any more
   | 
   | State-Changed-From-To: open->closed
   | State-Changed-By: jmmv%NetBSD.org@localhost
   | State-Changed-When: Fri, 12 Mar 2010 13:58:12 +0000
   | State-Changed-Why:
   | Nothing has happened in this ticket for a long time and pkg_comp works for 
me now.
 
 Please re-open this PR, I assure you it *DOES NOT* work now.
 
 I just moved aside my own (modified versions of pkg_comp and libkver,
 checked out the most up to date versions from CVS (not that either of
 those packages has been updated in ages) and tried a
 
        pkg_comp makeroot
 
 Aside with the problems caused by having a very old pkg_install in the
 sets installed in the pkg_comp sandbox (I use NetBSD 4.0 release sets)
 that seems to work, with "seems" being the operative word.
 
 Immediately after the makeroot completed ...
 
 jade# pkg_comp -ctest chroot
 PKG_COMP ==> Mounting sandboxed filesystems
 PKG_COMP ==> Entering sandbox `/local/pkg_comp/test'
 Cannot open "/libkver/lib/libkver.so"
 
 PKG_COMP ==> Unmounting sandboxed filesystems
 
 That's because pkg_comp is (attempting to) use the stanalone-install
 target that is part of libkver's Makefile (in pkgsrc), which you can
 see in ...
 
 # makeroot_libkver
 # 
 #   If NETBSD_RELEASE is set to a version string, installs libkver 
 #   inside the sandbox and configures it.
 # 
 makeroot_libkver()
 {    
     local prefix script statfile
 
     if [ "$NETBSD_RELEASE" != "no" ]; then
         _BUILD_TARGET="$BUILD_TARGET"
         BUILD_TARGET="standalone-install"
         pkg_build pkgtools/libkver 
         BUILD_TARGET="$_BUILD_TARGET"
         echo "LD_PRELOAD=${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so; export 
LD_PRELOAD" >> $DESTDIR/etc/shrc
         echo "setenv LD_PRELOAD ${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so" 
>> $DESTDIR/etc/csh.login
         echo "setenv LD_PRELOAD ${LIBKVER_STANDALONE_PREFIX}/lib/libkver.so" 
>> $DESTDIR/etc/csh.cshrc
         ln -s "$NETBSD_RELEASE" $DESTDIR/libkver_osrelease
     fi
 } 
 
 But the "standalone-install" target in libkver has been broken since
 some infrastructure change in pkgsrc ages (as in years) ago - and what's
 more, I think pkgsrc is correct, what the libkver Makefile is trying to
 do is insane.   What's more it is unnecessary, there are much better ways
 to achieve what pkg_comp needs than this nonsense.
 
 kre
 
 ps: personally I no longer care all that much, I use a heavily modified
 version of pkg_comp.  If I thought there was any interest in updating the
 version in pkgsrc, I'd send updates, but none of the ones I have sent before
 generated any interest at all (not even a "this is no good because...")
 so I got bored with sending them except where there's a direct bug that
 needs fixing (gnats does have patches for this particular problem as
 patches in some PR or other - you should ignore the patch in this PR though,
 that was an attempt to make standalone-install work, and while that actually
 works, it isn't the right way to handle this problem).
 
 pps: the (it seems too common) habbit of closing PR's just because they
 are "too old" really needs to be obliterated - eitehr a bug is fixed, or it
 is not fixed, if it is fixed (which includes never really existed), the PR
 should be closed for that reason.  If it is not understood, and the submitter
 can't be contacted, then that PR can also be closed, but if the bug is
 understood, or the original submitter is still having the problem (and is
 around to say so) then any PR should be left open, essentially forever (even
 after the system in which the bug was detected is no longer supported, unless
 it can be shown that the bug is not present in any supported version).
 


Home | Main Index | Thread Index | Old Index