Re: HEADS-UP: /bin/sh memory management bug fixes committed

["Thomas Mueller" <mueller6725%twc.com@localhost>]

from Robert Elz:

>    Date:        Mon, 19 Jun 2017 05:39:28 +0000
>     From:        "Thomas Mueller" <mueller6725%twc.com@localhost>
>     Message-ID:  <92.EA.01815.89367495@dnvrco-omsmta03>
 
>   | I suspect sh bug might have been at fault at least in part for
>   | pkg_rolling-replace strange behavior,
 
> That is possible.
 
>   | "make deinstall install".
 
> I generally do pkg_delete rather than make deinstall (had no idea such
> an option existed).   But otherwise, right.
 
>   | I have to consider the likelihood that many installed packages will no
>   | longer work after updating kernel and userland from 7.99.15 to 7.99.71
>   | to 8.99.1 because shared libraries figure to be out of sync.
 
> That should not be a problem, the only things that should need
> recompiling are things that depend upon osabi - usually I think that is
> far too strict, but in this case there's really no way it can know that
> nothing much has changed since (at least high) 7.99.nn versions and 8.99.1

> There might be an isolated package that uses one of the rarer libraries
> which might have been updated (particularly since 7.99.15) which you can
> solve either by recompiling (it, and everything else it depends upon
> which also might use the changed library) or you can just copy the
> libxxxx.so.N.M file from the old system to the new one (and perhaps
> the libxxx.so.N symlink which points at that one - I've never been sure
> exactly when that one is used).

> Just beware of mixing object files (which includes .so files) compiled
> and or linked using different versions of what is intended to be the same
> thing.  That leads to havoc.

> Apart from that I regularly run ancient compiled packages on newer
> systems, NetBSD people generally work very hard to make sure that remains
> possible.

> In fact, I usually compile all my packages against the N.0 RELEASE version
> (for whichever NetBSD version (N) I am using at the time) - that way one
> set of binary packages are all that are needed for all systems (of the same
> architecture, naturally) whatever actual N.p.q version I actually install on
> them.)

I updated NetBSD-current i386 successfully, but running pkg_rolling-replace failed miserably.

One barrier was package security/sudo, whether run from pkg_rolling-replace or from security/sudo directory:

ln -s sudo.8 /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/man/man8/sudoedit.8
/bin/sh ../mkinstalldirs /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo
for f in ./pam.conf ./sudo.conf ./sudoers  ./syslog.conf; do /bin/sh ../install-sh -c  -m 0644 $f /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo; done
/usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/doc/UPGRADE /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo
/usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/plugins/sudoers/sudoers /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/examples/sudo/sudoers
/usr/bin/install -c -o root -g wheel -m 644 /BETA1/pkgsrc/security/sudo/work899.i386/sudo-1.8.20p2/README /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/doc/sudo
=> Automatic manual page handling
=> Generating post-install file lists
/BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/group_file.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB)
/BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudo_noexec.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB)
/BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/sudoers.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB)
/BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/lib/sudo/system_group.so: installed without execute permission; fixing (should use [BSD_]INSTALL_LIB)
=> Checking file-check results for sudo-1.8.20p2
ERROR: ************************************************************
ERROR: The following files are in /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg but not in the PLIST:
ERROR:         /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/hu/LC_MESSAGES/sudo.mo
ERROR:         /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudo.mo
ERROR:         /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/ko/LC_MESSAGES/sudoers.mo
ERROR:         /BETA1/pkgsrc/security/sudo/work899.i386/.destdir/usr/pkg/share/locale/nn/LC_MESSAGES/sudo.mo
*** Error code 1

Stop.
make[2]: stopped in /BETA1/pkgsrc/security/sudo
*** Error code 1

Stop.
make[1]: stopped in /BETA1/pkgsrc/security/sudo
*** Error code 1

Stop.
make: stopped in /BETA1/pkgsrc/security/sudo

I don't know if this would do any better on amd64.  

I suppose I could try editing the PLIST and then "make install"?

But then I guess this belongs on a new thread on pkgsrc-users.  I don't really think this is the fault of /bin/sh any more.

Next updates to do are NetBSD-current amd64 and FreeBSD 11.1-PRERELEASE amd64.

Tom