Re: libpoppler mismatch for pdflatex

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

maya%netbsd.org@localhost writes:

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

I don't see why manually-installed matters.  If something else depends
on the package that it wants to update, that something might well break.

Really, if installing wants to update, then a warning is in order:

  It appears that you have some packages from an older build of pkgsrc,
  and are now installing packages from a newer build.  This is unlikely
  to work correctly.  Perform a full upgrade of all packages [Y/n]?

and if no:

  Packages may be inconsistent.  Note that existing packages will not be
  upgraded for this installation, and thus installation of requested new
  packages may fail.  Proceed [N/y]?

but I'm probably being a bit pedantic.

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

That makes sense.

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

I can't see it being feasible to do this in pkgsrc; it will result in
shlib versions being wildly out of sync with upstream.