pkgsrc-Bugs archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

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



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 10:20:39 +0100

 * On 2020-08-28 at 22:50 BST, Joerg Sonnenberger wrote:
 
 > On Fri, Aug 28, 2020 at 04:15:02PM +0000, Thomas Klausner wrote:
 > > The following reply was made to PR pkg/55593; it has been noted by GNATS.
 > > 
 > > From: Thomas Klausner <wiz%NetBSD.org@localhost>
 > > To: NetBSD bugtracking <gnats-bugs%NetBSD.org@localhost>
 > > Cc: 
 > > Subject: Re: pkg/55593: Proposed modification to buildlink3.mk of libxml2
 > > Date: Fri, 28 Aug 2020 18:12:37 +0200
 > > 
 > >  On Fri, Aug 28, 2020 at 04:05:09PM +0100, Jonathan Perkin wrote:
 > >  > * On 2020-08-21 at 18:59 BST, Joerg Sonnenberger wrote:
 > >  > 
 > >  > > On Thu, Aug 20, 2020 at 03:40:00AM +0000, you.kawasaki%gmail.com@localhost wrote:
 > >  > > > I noticed that the CFLAG does not include "include/libxml2".
 > >  > > > When I added following line in buildlink3.mk of libxml2 to include "include/libxml2" in the CFLAG, building finished without an error for handbrake.
 > >  > > 
 > >  > > So the short version is that this $#%^$%^$%^ hardcodes include paths for
 > >  > > various systems and for Linux it falls through to explicitly using
 > >  > > /usr/include. It should be using pkg-config like everyone... libxml2's
 > >  > > b3.mk should most definitely not be changed for compensating for such a
 > >  > > mess.
 > >  > 
 > >  > FWIW I just ran into this on a system building www/nginx also.
 > >  > 
 > >  > I don't see any _harm_ in adding the correct INCDIRS, it's what we do
 > >  > for a lot of other packages, so I'm going to add it unless there are
 > >  > serious objections.
 > >  
 > >  If you do it in the package that fails that's definitely fine.
 > 
 > I don't mind doing it in the leaves, but I do object to adding it to
 > libxml2's b3.mk. Essentially, this is a hackaround for a steaming
 > U+1F4A9 and the package here is definitely broken.
 
 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...
 
 Fine, I'll go around adding patches for everything that breaks due to
 this, but it feels very against the pkgsrc philosophy, will mean
 constant future maintenance burden, and inconsistency in how different
 packages resolve the problem.
 
 -- 
 Jonathan Perkin  -  Joyent, Inc.  -  www.joyent.com
 


Home | Main Index | Thread Index | Old Index