Re: mk.conf error from pkg_chk (Was: openjdk21 build errors)

[Jonathan Perkin <jperkin%pkgsrc.org@localhost>]

* On 2025-01-28 at 23:25 GMT, Roland Illig wrote:

> Once you have pkgsrc source and pkgsrc binary set up, chances are low
> that one of them moves to a different location.  And even if that's what
> happens, you can simply rebuild pkg_check to update the PKGSRCDIR that
> would be hardcoded in the pkg_chk binary.
>
> For example, lintpkgsrc also hardcodes PKGSRCDIR during the build, plus
> a good guess for LINTPKGSRC_MAKECONF. The latter has been hardcoded
> since 2022, and I didn't receive any complaints about it.
>
> Before 2015, pkglint also hardcoded PKGSRCDIR, but since it is obvious
> from each pkglint invocation what to check and look for a nearby
> ../mk/bsd.pkg.mk, newer pkglint doesn't need this hardcoded variable
> anymore.
>
> Am I missing some point here why hardcoding PKGSRCDIR would be bad?

Binary package repositories.  lintpkgsrc from my package repositories 
hardcodes some per-build Jenkins workspace directory that will never be 
correct for anyone running it locally on their systems, even myself.

Yes, they'll have to override it anyway, and one could argue that most 
tools that hardcode PKGSRCDIR are unlikely to be useful in a binary 
context, but I hit this often enough (e.g. using a binary repo build of 
lintpkgsrc on different trees) that it smells like a bad wart.

I'd prefer it to require either an explicit option or auto-detection.

--
Jonathan Perkin                    pkgsrc.smartos.org
Open Source Complete Cloud   www.tritondatacenter.com