Date: Mon, 19 Jun 2017 05:39:28 +0000 From: "Thomas Mueller" <mueller6...@twc.com> 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.) kre