On 2019-05-02 15:47, Sijmen J. Mulder wrote:
That would be really nice, but sounds like an awful lot of work to implement and maintain.Hi, Buildlink exposes /lib, /usr/lib and such because those aren't thought to pollute the build environment. This is true on BSD and macOS but not on most Linux distributions where that distinction isn't as clear. I found some of my own packages didn't build on a fresh Debian install that didn't include packages like ncurses or zlib. Wouldn't it be better to mask the system directories as well and only link builtins are that are explicitly depended upon? I'm not sure how we'd deal with headers, perhaps masking just the lib/ directories would be a better start. Or perhaps I'm completely misguided. Sijmen
I get around most of these issues on CentOS by testing in the most minimalist environment possible, e.g. a chroot env with nothing but gcc and openjdk installed via Yum.?? This exposes any missing dependencies, although on rare occasions leakage from /usr/* may still break a build of a tested package when performed on a less pristine installation.
Most leakage issues I've experienced have been in the other direction, though: Package tested on a non-pristine system and doesn't list all dependencies because if depends on things from outside pkgsrc, so it fails on minimal systems like your Debian install.
Pkgsrc does a very good job prioritizing its own content, especially if you add the following to your mk.conf:
PREFER_NATIVE=?????? ?????? no PREFER_PKGSRC=?????? ?????? yesThe few exceptions are usually the result of upstream build systems with hard-coded search paths, which should be patched to respect the environment anyway.