Re: ghostscript-agpl, netbsd-7, freetype2

[Gavan Fantom <gavan%coolfactor.org@localhost>]

On 17/12/2017 01:15, Greg Troxel wrote:
> David Holland <dholland-pkgtech%netbsd.org@localhost> writes:
>
> > On Wed, Dec 13, 2017 at 07:23:02AM -0500, Greg Troxel wrote:
> >   > With that line (in ghostscript-agpl's Makefile, just before the
> >   > inclusion of freetype2's buildlink3.mk), I can look at variables and see
> >   > that the builtin is still selected.  Running pkg_admin pmatch shows that
> >   > the original API_DEPENDS that comes by default is satisfied but the new
> >   > one is not, and there is some loop logic that I think is supposed to
> >   > make sure all are met, but I don't quite follow the make code.
> >
> > Debugging this stuff is a giant pain (IME you have to start stuffing
> > lines of the form "FOO!=echo foo 1>&2" into the builtin logic to see
> > what's reached) but the first and relatively easy thing to check is
> > what version of the builtin package it detects:
> >
> >     make show-var VARNAME=BUILTIN_PKG.freetype2
> >
> > because it's not uncommon for this to turn out to be rubbish, and then
> > none of the rest matters.
> $ make show-var VARNAME=BUILTIN_PKG.freetype2
> freetype2-2.5.5
>
> $ make show-var VARNAME=BUILDLINK_API_DEPENDS.freetype2
> freetype2>=2.4.5 freetype2>=2.8.1
>
> $ make show-var VARNAME=USE_BUILTIN.freetype2
> yes
>
> $ make show-var VARNAME=CHECK_BUILTIN.freetype2
> no
>
> But I think the problem might be in freetype2/buildlink3.mk, where
> CHECK_BUILTIN.freetype2 is set to no, as part of dealing with a png
> dependency.
>
> (With hack from fontforge, ghostscript-agpl builds, but I believe that
> something is still not right.)

This has come up again for me today as I am building ghostscript-agpl on 
NetBSD 7. The recent upgrade of ghostscript-agpl now requires 
freetype2>=2.10.0, although that dependency isn't actually stated in the 
Makefile.

I tried to add:

BUILDLINK_API_DEPENDS.freetype2+= freetype2>=2.10.0

... and had the same problem as you, that it doesn't actually influence 
the choice made in builtin.mk.

This is actually nothing to do the the pmatch logic - that's not even 
executed. What's happening is actually in fonts/fontconfig/builtin.mk:

CHECK_BUILTIN.fontconfig?=      no
.if !empty(CHECK_BUILTIN.fontconfig:M[nN][oO])

.  if !empty(USE_BUILTIN.fontconfig:M[nN][oO])
BUILDLINK_API_DEPENDS.fontconfig+=      fontconfig>=2.1nb2
BUILDLINK_API_DEPENDS.freetype2+=       freetype2>=2.1.3
.  endif

.  if !empty(USE_BUILTIN.fontconfig:M[yY][eE][sS])
USE_BUILTIN.expat=      yes
USE_BUILTIN.freetype2=  yes
USE_BUILTIN.zlib=       yes
.  endif

.endif  # CHECK_BUILTIN.fontconfig


This is executed before freetype2's builtin.mk, and so it is not given 
the opportunity to check if the built in freetype2 is even suitable.


I note that higher up in the file there's also this:

# These are dependencies of fontconfig.  If we need to use the pkgsrc
# versions of any of these, then also use the pkgsrc version of
# fontconfig.
#
.if defined(USE_BUILTIN.zlib) && !empty(USE_BUILTIN.zlib:M[nN][oO])
USE_BUILTIN.fontconfig= no
.endif
.if defined(USE_BUILTIN.freetype2) && 
!empty(USE_BUILTIN.freetype2:M[nN][oO])
USE_BUILTIN.fontconfig= no
.endif
.if defined(USE_BUILTIN.expat) && !empty(USE_BUILTIN.expat:M[nN][oO])
USE_BUILTIN.fontconfig= no
.endif


Now, buildlink3 already has functionality to force using pkgsrc versions 
of any packages which have dependencies which are using pkgsrc versions, 
so that section seems redundant. What I'm less sure of is whether 
there's any good reason why we should still be forcing the builtin 
version of dependencies - surely each package knows best, and we should 
only use the native version if all packages in that dependency tree are 
suitable, which is what buildlink3 would do anyway?

So I think the right fix is to simply remove those sections (at least 
the higher section, and the part of the lower section that sets 
USE_BUILTIN...) from fonts/fontconfig/builtin.mk.

Before I commit this, can anyone think of a good reason why they need to 
remain?