Re: Help with package that has a build dependency on a Linux binary

[Greg Troxel <gdt%lexort.com@localhost>]

Jason Thorpe <thorpej%me.com@localhost> writes:

> I'm working on a package update that has a dependency on a Linux
> x86_64 binary for which sources are not available.  I have the package
> building on my local NetBSD/amd64 system, with the suse_base-13.1nb15
> emulation package installed.  This is only a build-time dependency.
> Once built, the single package can be installed on any system (it's a
> u-boot package, so nothing actually runs on the system you install it
> on -- it's just a blob that's blasted on an SDMMC card later).
>
> Because this tool is really only useful for this particular package,
> I'm loathe to make a separate package just for it (and eventually,
> open source replacements for this tool may work, but for the moment,
> they don't).

I don't see why that means it shouldn't be a package.   Package entries
are pretty cheap, and "go get this code and make it available to run" is
exactly what a package is.  So I think you should just package the
proprietrary tool.

> Right now, my work-in-progress just downloads the binaries from the vendor, chmod's them, and runs them from $DISTDIR, and I have:
>
> BUILD_DEPENDS+=         suse_base>=13.1nb15:../../emulators/suse131_base
>
> ...to express the dependency on the Linux emulation package (it may work with an older one, but I haven't tried it, and nor am I likely to).

Sure, that's fine.  In the glorious future, when crossbuilding of pkgsrc
is straightened out, we will have stricter notions of TOOL vs DEPENDS
and this binary you are talking about presumably should be for the host.
Another reason why making it a package makes everything simpler.

> This particular u-boot package is also part of the u-boot meta
> package, and I guess I'd like some way to express "optionally depends
> on" for that.

If you mean, in options.mk, you add a depends only if an option is
enabled, that should be straightforward.  Otherwise (and I think you
know that, so I suspect we are at otherwise), I don't understand.