Re: libpoppler mismatch for pdflatex

[maya%netbsd.org@localhost]

On Mon, Jan 28, 2019 at 06:31:25AM +0000, maya%netbsd.org@localhost wrote:
> 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 ?!?!?!)

The better fail scenario where it fails (btw) is:


	[poppler]
       /         \
[lib A]		[lib B]
       \	 /
        \	/
	[binary]

partially updating one side of this (poppler, lib A, binary) will fail
unpredictably if lib B.

Suppose libA calls poppler_do_action, and libB calls poppler_do_action
too. Whether the old or new poppler function is used is unreliable.

If they are the same - no problem.
If it changed - random runtime crashes.