[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: RHEL/Centos 7 builtin vs pkgsrc zlib clash for Makefiles that include devel/zlib/buildlink3.mk
On 2020-08-16 10:32, Greg Troxel wrote:
I agree that this is a bug in the current framework. Note that the
problem is triggered by a change to PREFER_NATIVE after packages are
installed, though. So I think the first question is whether we want to
support such changes. If so, then this will have to be addressed.
Jason Bacon <outpaddling%yahoo.com@localhost> writes:
Right, the problem, put another way, is that in the absence of
PREFER_PKGSRC or PREFER_NATIVE, the current run time logic will link
to pkgsrc libz if it's there, but won't install it if it's not. Since
libz is a dependency of something installed during bootstrap, we have
to explicitly set PREFER_PKGSRC during bootstrap to make sure every
dependent package is using pkgsrc libz. One theoretical fix would be
to automatically mark dependencies PREFER_NATIVE when they're
implicitly chosen a link time. I'm not sure how difficult this would
be. In any case, setting PREFER_PKGSRC=yes + PREFER_NATIVE=list
during bootstrap should prevent this problem.
I see it as a fundamental bug to make the native/pkgsrc choice depend on
whether it is installed. That seems counter to the notion of declared
dependencies and repeatable outcomes. Perhaps I don't get something,
but it seems like that bug should be fixed.
That might just expose the "picking system and pkgsrc in a mix-and-match
way doesn't work because of rpath having to list one first, and thus
getting a package to link with system at run-time when pkgsrc exists
doesn't really work.
If so, that lands us back on "it's not ever ok to use system lib of
foo", for each foo where this is trouble.
As of this moment, it's not possible to set PREFER_NATIVE during
bootstrap, so users cannot avoid this issue if it involves packages
installed by the bootstrap script. The bootstrap patch I'm about to
commit will fix that by adding a --prefer-native flag.
The simplest solution is to cast both PREFER_PKGSRC and PREFER_NATIVE in
stone during bootstrap and make sure anything marked PREFER_NATIVE never
gets installed from pkgsrc. I think the current logic should already
prevent installing the pkgsrc package as a dependency (barring pkgsrc
bugs) and installing it explicitly when it's listed in PREFER_NATIVE
would be a blatant enough user error that it's not on us to prevent it.
So if we're ready to tell users that we don't support changes to
PREFER_* after bootstrap, I think this issue is resolved. Otherwise, we
may have some difficult work ahead.
Main Index |
Thread Index |