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.
Attachment:
signature.asc
Description: PGP signature