Re: pkg_install fails when archivers/xz is installed

["Lai, Peter PW" <peter.lai2%prattwhitney.com@localhost>]

> -----Original Message-----
> From: pkgsrc-users-owner%NetBSD.org@localhost [mailto:pkgsrc-users-
> owner%NetBSD.org@localhost] On Behalf Of Greg Troxel
> Sent: Sunday, August 9, 2020 2:08 PM
> To: Jason Bacon <outpaddling%yahoo.com@localhost>
> Cc: Pkgsrc users <pkgsrc-users%netbsd.org@localhost>
> Subject: [External] Re: pkg_install fails when archivers/xz is installed
> 
> 
> 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.

The official instructions for using Oracle Instantclient on Linux without needing
root is to munge LD_LIBRARY_PATH with the path of the instantclient :)
(if you have root, Oracle tells you to munge /etc/ld.so.conf.d instead...)
https://www.oracle.com/database/technologies/instant-client/linux-x86-64-downloads.html#ic_x64_inst

This in particular has become a pretty mainstream use case in enterprise environments
because of the cx-Oracle Python module. I believe some other stuff in academia
still need LD_LIBRARY_PATH munging also (FlexLM I'm looking at you!)

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

I agree that the default should be to default to PREFER_PKGSRC unless explicitly
set that way by people-who-know-what-they're-doing.