Re: pkg/55593: Proposed modification to buildlink3.mk of libxml2

[Jonathan Perkin <jperkin%joyent.com@localhost>]

The following reply was made to PR pkg/55593; it has been noted by GNATS.

From: Jonathan Perkin <jperkin%joyent.com@localhost>
To: Joerg Sonnenberger <joerg%bec.de@localhost>
Cc: gnats-bugs%netbsd.org@localhost, pkg-manager%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
	pkgsrc-bugs%netbsd.org@localhost, you.kawasaki%gmail.com@localhost
Subject: Re: pkg/55593: Proposed modification to buildlink3.mk of libxml2
Date: Thu, 3 Sep 2020 17:53:08 +0100

 * On 2020-09-03 at 14:55 BST, Joerg Sonnenberger wrote:
 
 > On Thu, Sep 03, 2020 at 09:25:02AM +0000, Jonathan Perkin wrote:
 > >  So why do we bother having BUILDLINK_INCDIRS in the first place?  What
 > >  problems are we solving by having to patch every leaf instead of just
 > >  fixing this in the infrastructure like we do for everything else?
 > >  What possible side-effects are there of adding include/libxml2 for
 > >  _only the configured libxml2_ to the search path?  It's not like we're
 > >  going to accidentally find some incompatible libz in there or
 > >  something...
 > 
 > Did you read what I said why this is failing in first place? All sane
 > build systems work fine because they use pkg-config already. This #$%#$%
 > is singular shit by deciding that Linux must have things in /usr/include
 > and hard-coding that. So no, I do not want to penalize everything
 > everywhere just for the sake of one or two crappy packages.
 
 Software is broken.  News at 11.  That's why we develop pkgsrc
 infrastructure to fix things large-scale where possible rather than
 having to patch individual packages.
 
 And still doesn't explain why adding BUILDLINK_INCDIRS *penalizes*
 anything.  It can only ever possibly point to the directory that has
 been deliberately chosen as where the correct software lives, and only
 when that software has been deliberately chosen to be enabled.
 
 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com