Re: Libreoffice: Error about /usr/lib/libstdc++.so.7

[Greg Troxel <gdt%lexort.com@localhost>]

Bruce Nagel <nagelbh%sdf.org@localhost> writes:

> NetBSD Bast 9.3 NetBSD 9.3 (GENERIC) #0: Thu Aug  4 15:30:37 UTC 2022  mkrepro%mkrepro.NetBSD.org@localhost:/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.