pkgsrc-Users archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pkg_install fails when archivers/xz is installed

On 2020-07-29 10:55, Greg Troxel wrote:
Jason Bacon <> 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,
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.

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

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.

Home | Main Index | Thread Index | Old Index