Re: libpoppler mismatch for pdflatex

[maya%netbsd.org@localhost]

On Sun, Jan 27, 2019 at 08:08:15PM -0500, Greg Troxel wrote:
> Understood.  What I meant is that given how pkgsrc works, with
> a recursive PKGREVISION++ when a shlib major changes (really, when an
> ABI changes), then package managers have to behave in certain ways.
> Generally, the advice is that all packages must be built from a
> consistent pkgsrc tree, either a quarterly branch (where we in theory
> attempt not to change ABIs), or HEAD from some moment in time.
> 
> Given that, having pkgin update a package behind one's back while asking
> for an update, seems like a bug.  Really once the repository has
> changed, it's necessary for soundness to do an update of all installed
> packages to the versions in the new repository before installing any new
> packages.  Of course, often one can get away with less.

We have a way to make it not too user hostile:

if (set of packages that have to be updated) include another
manually-installed package, ask for confirmation.

> 
> So really I am questioning the wisdom of having an install command
> change any currently-installed package.
> 
> > If we are lucky, "don't delete the stale file" will do the right thing.
> 
> Sometimes, but if e.g. both libfoo.so.8 and libfoo.so.9 are both called
> for by different dependencies, that seems like a mess.  I guess in the
> base system it tends to work,

The way it works it holds up is we major bump all the other libraries
depending on it too, so no conflicts are going to happen.
We have the ability to represent this within pkgsrc but uhmm big project
and I think joerg will have some esoteric scenario he picks up where I
can't rename bl3 PKGREVISION -> SONAMEBUMP and get the right thing.

Certainly, with libGL in netbsd this has been a problem because things
are expected to hard-code "dlopen libGL.so.1" (it even got documented as
the way to do it ?!?!?!)