Jason Bacon <outpaddling%yahoo.com@localhost> writes:
ld and ld.so have basically the same priorities. However, a little
more digging revealed that rpath is dying a slow death in the linux
world and at some point in the future LD_LIBRARY_PATH will likely have
the highest priority even on RHEL/CentOS.
That all seems very strange, but it is how it is.
So the only option for protecting users form themselves will probably
be to scrub the env, which I'm also doing already. auto-pkgsrc-setup
generates two variants of env modules and startup scripts:
1. One that scrubs the env of PATH, LD_LIBRARY_PATH, CFLAGS, etc. This
is necessary for clean package builds and recommended for most users
running them.
2. Another tagged "-non-exclusive" which leaves the users' env intact
and simply prepends pkgsrc dirs to PATH.
Up to you! I luckily do not have to support such users, on systems
where the culture is to have to use LD_LIBRARY_PATH to work around
programs that aren't installed corretly.
I don't think any core pkgsrc change is necessary since this is
already fairly well-supported by PREFER_PKGSRC/PREFER_NATIVE. I would
only aim to educate people about their use.
If the consensus is that on Linux, because of old libs (FC derivatives)
or unstable libs, people should steer hard to PREFER_PKGSRC, we should
set the defaults that way. As pkgsrc maintainers, we curate decisions
in the best interests of most users, in addition to providing knobs for
others. You have made what feels like a strong argument that using base
libs that could have been avoided isn't generally a good idea.
This is based on 8 years experience using pkgsrc on CentOS and
figuring out ways to prevent problems. Except for a few edge-cases
like curl requiring mozilla-rootcerts and reasonable arguments against
making it a dependency, we've had almost no surprises in the past few
years.
My point is that if you have come to the conclusion that the right way
for pkgsrc to be built on most GNU/Linux is to PREFER_PKGSRC then I
think we should, absent objections, make it the default. I do not think
it is reasonble to say "The default is X but you should do Y, so
therefore when you build...". If that's the recommendation, it should
just happen.
The potential issues with changing shared libs on bleeding-edge
distros is more speculative, but I think pretty obvious. On CentOS,
S.O. versions almost never change, so we don't worry about ABI
changes. But we occasionally had issues early-on with Yum libraries
appearing or disappearing, which causes similar results if
PREFER_PKGSRC is not used. A Yum autoremove can remove a shared lib
that pkgsrc depends on, causing existing pkgsrc binaries to
fail. Likewise, installing a Yum package with different build options
than the pkgsrc equivalent might cause pkgsrc binaries to fail if they
decide to grab the Yum version. The same could happen with Debian's
apt, Gentoo Portage, or any other foreign installations. When pkgsrc
manages most of its own dependencies, issues like these become almost
non-existent. I don't recall encountering one since I started using
PREFER_PKGSRC=yes, except a few WIP packages that didn't utilize rpath
properly.
This seems to argue for changing the default.
Do you intend to change it, or do you think there is some reason not to,
or that others object? As I said above, my only goal here is that we
adjust defaults to the consensus of best practice.
I don't think "somebody might want to prefer base" is a good reason not
to change. If that's 75% of users, sure, but if it's small, then they
can set options. Plus, the question is what happens to people in each
camp if they build not how they should have. It seems PREFER_PKGSRC
will merely just build too much, but it will work.