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

[Bruce Nagel <nagelbh%sdf.org@localhost>]

On Mon, Aug 07, 2023 at 09:06:34AM -0400, Greg Troxel wrote:
> 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.

Using either my original pkgsrc url that e.g. url I get this error when trying
to do 'pkgin upgrade':

pkgin: empty local package list.

'pkgin list' gives the same: Requested list is empty.

'pkgin stats':

Local package database:
        Installed packages: 546
        Disk space occupied: 7566M

Remote package database(s):
        Number of repositories: 1
        Packages available: 24863
        Total size of packages: 38G
'pkg_admin check' gives a lot of errors to the effect of:

pkg_admin: libreoffice-7.5.1.2: File `/usr/pkg/libreoffice-7.5.1.2/lib/libreoffice/sha
re/extensions/dict-is/license.txt' is in +CONTENTS but not on filesystem!

but mentions no other packages, just libreoffice.

'pkg_info -a' gives a long list of packages that looks like what I have
installed.

If I try to do: 'pkgin install libreoffice' it now offers to install it,
without the libsdtc++ error it was giving before, but due to the 'empty
package list' error I have not done that yet, figuring there's a bigger
issue to resolve.

> > 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.

Upgrading individual packages is apparently a bad habit from my days running
Debian.  My impression was that apt-get checked for those sorts of cross-package
library version issues and prompted you for decisions if there was a conflict.
I seem to recall more libraries were in separate packages of their own which
probably made that easier for it to do.

> 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.

From here on out I'll just do pkgin upgrade, better safe than sorry.

I just need to resolve the 'empty package list' issue first.

Thank you,
Bruce
--
It is only through labor and painful effort, by grim energy and resolute
courage, that we move on to better things.
(Theodore Roosevelt)