Re: pkg_install fails when archivers/xz is installed

[Jason Bacon <outpaddling%yahoo.com@localhost>]

On 2020-07-29 10:55, Greg Troxel wrote:
> Jason Bacon <outpaddling%yahoo.com@localhost> writes:
>
> > 1. Point RPATH at the system lib directory (probably /usr/lib or
> > /usr/lib64, but platform-dependent).
> system libs are searched by default so having RPATH to them seems like
> asking for trouble.
The point here is not to add system lib dirs, but to exclude 
${PREFIX}/lib.  It's my understanding that RPATH overrides all other 
search paths, so this would ensure that pkg_install binaries don't get 
fooled into using the wrong libs by LD_LIBRARY_PATH and such.


> > 2. Don't set RPATH at all (I think this is what Joerg was
> > suggesting).  System dirs should come first in the default path, but
> > might be affected by other mechanisms such as ldconfig,
> > LD_LIBRARY_PATH, etc.
> People how set paths by ldconfig and LD_LIBRARY_PATH get the results
> they ask for.  I wouldn't worry about them, absent a good argument for
> why some particular setup is rational.
LD_LIBRARY_PATH should be respected in some situations, but I don't 
think this is one of them.  I think allowing users to break pkg_add or 
other critical tools just by setting an env variable would be bad PR for 
pkgsrc.  I can't think of a situation where it would be wise for an 
end-user to force pkgsrc binaries to use an outside library instead of 
the one that's vetted by pkgsrc.

When I see people using LD_LIBRARY_PATH, it's invariably for some 
cave-man installed software in their home directory and they don't 
expect it to have side-effects on things installed by a package manager.

> What I meant to say is that I don't understand where that RPATH setting
> is coming from in the build, which is probably deep in bl3 files and
> wrappers.   I suggest enough tracing to figure out where it is coming
> from and why, and then evaluating whether that is buggy.  Right now  we
> just don't know.
Agreed.
> > 3. Bundle all dependencies and either isolate them as shared libs in a
> > special directory pointed to by RPATH (e.g. /usr/lib/pkg_install/) or
> > statically link everything.  This has the potential advantage of
> > consistent features and versions across all platforms.  It appears
> > that currently some features like XZ support are enabled only if
> > appropriate headers are found in the base system.
> This seems really awkward, compared to option 2.  Before doing this, I
> think we should have a really clear understanding of what is going on.
Agreed.  This is a laborious solution, but it's one to consider.
> Option 4 is to figure out why pkgsrc liblzma is ever built on this
> system, when the base system version is adequate.  Basically we need to
> have a consistent decision about good enough or not good enough, and
> this is generally true about bhiltin detection.  We have had cases where
> base had version X and that was good enough for some things but other
> things needed X+1 and pulled in pkgsrc.  This went really badly and we
> resolved it by making builtin detection require a version that was
> generally good enough, not just for the current program, but anything
> normal.
>
> Why is the library installed in pkgsrc?  What if you pkg_delete that?
> If something depends on that, why doesn't it use the base version?
As I've stated before on this list, I'm leery of having my pkgsrc 
installations rely on anything outside their control.  On CentOS 
systems, for example, most Yum packages never get upgraded until you 
upgrade the major version of the OS.  They only get bug fixes and 
security patches.  So while pkgsrc is keeping up with the latest 
releases, "base" liblzma is standing still for the several years the 
system is in service and eventually it may be too old for pkgsrc to use.

On Debian bases systems, it could mean a library getting upgraded behind 
our backs by apt upgrade, resulting in an ABI/API change that suddenly 
breaks a pkgsrc binary that's been working fine until now.

With all the platforms we support, I think there are just too many 
possible variants of a given library and too many possible problems for 
us to keep up with, so I always set PREFER_PKGSRC to minimize unpleasant 
surprises.

Setting acceptable versions will help, but versions aren't always the 
only variable.  Sometimes there are build options to enable/disable 
features that could affect us.  I've been hit by this a few times in the 
past, but I don't recall the specific software in question.  Maybe boost?

> I am assumign that you have not changed the base system during all
> this.  (If you did, the answer is don't do that!)
One change: "yum remove xz-devel" and bootstrapped a new pkgsrc tree, 
which is working fine now.