Bruce Nagel <nage...@sdf.org> writes: > NetBSD Bast 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug 4 15:30:37 UTC 2022 > mkre...@mkrepro.netbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC amd64 > > packages are coming from: > http://cdn.NetBSD.org/pub/pkgsrc/packages/NetBSD/amd64/9.3/All
OK, not super surprising, but could have been all sorts of things That is likely still packages from 2023Q1, but 2023Q2 packages are mostly built, perhaps fully. You may wish to use a URL with an explicit quarter rather than relying on the symlink, e.g. https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/amd64/9.0_2023Q2/All/ however, as always, you should make a backup before you start. > Currently-installed gcc reports its version as 7.5.0nb4, 7.5.0nb6 is to be > installed. The /usr/lib/ file you reported as something complaining about is from the base system. I would see if it exists. (In general c++ is difficult to deal with as different compiler versions are not ABI compatible, and I suspect that is part of the issue.) > So standard NetBSD/pkgsrc practice is to do a 'pkgin upgrade' rather than > upgrading individual packages using 'pkgin install <package>' as one might do > on e.g., a Linux system? Well, in theory there are dependency rules and pkgin should not let you violate them. However often a new package will want a dependency which is newer than one you have installed. And then something else you have installed will have had a dependency replaced out from under it, and it's hard to say if it will be ok. To get concrete progA 3 and libX 1 are installed from 2022Q4 time passes, wait until 2023Q2 is available. Now, progA and libX both have new versions in the repository, progA 4 and libX 2 pkgin install progB which is at version 5 let's say progB also depends on libX 2 so it upgrades libX to 2, and installs progB 5 but now, progA 2 is expecting libX 1 and doesn' have it maybe, it's possible that pkgin recognizes this and rejects the installation, or maybe it upgrades progA. But knowing if a binary package that is installed will be ok with a new dependency is basically unsolvable. I view it as a clue that I don't understand what happens in these partial upgrade scenarios. I think it's just asking for trouble and I don't do it. That doesn't mean it can't, shouldn't or doesn't work. I am unclear on what happens in say Debian (as this is about a package manager not the kernel). But the choices are basically: don't allow upgrading something if there is a depending package not being upgraded if a package is upgraded, refresh/upgrade everything that depends on it somehow have data about what is an ABI break and what will work upgrade it anyway and break I would expect Debian does one of the first two, but on the two Debian systems I deal with, I just 'apt update' and 'apt upgrade' and have thus never had a reason to figure it out. This is why I am recommending that for binary packages with pkgin, you pick a consistent build and "pkgin upgrade" to it, so that all our packages are from the same consistent build.
