[Pkg-running-devel] Bug#819998: Bug#819998: garmin-forerunner-tools: FTBFS on !linux after switch to libusb 1.0

Steven Chamberlain steven at pyro.eu.org
Tue Apr 5 10:51:16 UTC 2016

# waiting on more info from me; see last paragraph
tags 819998 + moreinfo


Christian PERRIER wrote:
> I suppose that this probably affects several packages and not this
> one, only. If so, are there guidelines somewhere about Doing The Right
> Thing?

On kfreebsd we have a libusb2-dev, a different codebase that
provides an interface generally compatible with libusb-1.0 (and others).

Although it has a Provides: libusb-1.0-0-dev, that can only work if the
Build-Depends: libusb-1.0-0-dev doesn't specify a version constrain, and
in this case it does.

This is quite common.  So I typically recommend this:

    Build-Depends: libusb-1.0-0-dev (>= 1.0.9) [!kfreebsd-any], libusb2-dev [kfreebsd-any]

and I perhaps should add this to some porting FAQ.  Or, perhaps
someone can suggest something better we could do than the Provides:.
(Also note the comma between the alternative dependencies;  a pipe does
not do the obvious thing).

For hurd, there is no USB stack yet, so... I guess there is no solution
at the mooment.  When there is, I'm not sure what the Build-Depends will
need to be.  With the above, it would stay BD-Uninstallable on hurd,
waiting on libusb-1.0-0-dev, which is nice for porters to see clearly it
is waiting on USB support.  The out-of-date package can be decrufted on
hurd-i386 if it is non-functional without USB.

On kfreebsd, the next problem is that garmin-forerunner-tools
./configure uses /usr/bin/$(DEB_HOST_GNU_TYPE)-pkg-config and not the
regular pkg-config.  It scans only the multiarch path such as:


but on kfreebsd it cannot find the libusb-1.0.pc provided by


because we did not convert libusb2-dev to multiarched paths yet.

This is the first time I'm seeing this;  I suppose it is caused by
--host=$(DEB_HOST_GNU_TYPE).   I could multiarch libusb2-dev, but I
worry some other packages do the opposite, and look in only
/usr/lib/pkgconfig and not the multiarch paths...

I think I should look into that, do some test rebuilds of reverse-deps
in the archive, and then get back to you.

Steven Chamberlain
steven at pyro.eu.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-running-devel/attachments/20160405/21a84956/attachment.sig>

More information about the Pkg-running-devel mailing list