Daniel Gustafsson <dan...@yesql.se> writes:
> On 13 Mar 2020, at 17:14, Tom Lane <t...@sss.pgh.pa.us> wrote:
>> Yeah, that's the argument *for* back-patching. Question is whether it
>> outweighs the risk of silently breaking somebody's build by linking
>> to the wrong libxml2 version.
> Correct, my argument is that breakage can be expected equally across branches,
> so I think back-patching should be seriously considered.
You're right that the risk of breakage (of either type) is about the same
across branches; but the project's conventions are not. We try to avoid
unnecessary changes in back branches.
Still, after further reflection, I think the odds favor back-patching.
This patch could only break things on systems where
(a) There's more than one libxml2 installation, which is already a
tiny minority use-case. It seems very unlikely to hurt any packagers
following typical build processes, for instance.
AND
(b) the default pkg-config and default xml2-config results differ.
That seems even more unlikely.
Now, breakage is certainly possible. A counterexample to (b) is that
if you wanted to build using a non-default libxml2 installation, you
might've tried to select that by putting its xml2-config into your
PATH ahead of the system version, rather than setting XML2_CONFIG.
Post-patch, we'd consult pkg-config first and presumably end up
with the system libxml2.
Still, I think the number of people who'd get bit by that could be
counted without running out of fingers, while it seems quite likely
that many people will soon need to build our back branches on
platforms that won't have xml2-config.
So I'm now leaning to "back-patch and make sure to mention this in
the next release notes". Barring objections, I'll do that soon.
> Absolutely, thats why I referred to changing mentions of libxml in the docs
> only where we refer to the product and not the switch (the latter was not very
> clear in my email though). Also, shouldn't libxml2 be within <productname>
> tags like OpenSSL and LLVM et.al?
I don't have a problem with s/libxml/libxml2/ in the running text
(without changing the switch name). Can't get too excited about
<productname> though. I think we've only consistently applied
that tag to PostgreSQL itself.
regards, tom lane
