Re: Weird ALTERNATIVES and staging conflict.

[Richard Purdie <richard.purdie@linuxfoundation.org>]

On Thu, 2014-10-30 at 15:17 +0100, Mike Looijmans wrote:
> I have this base script that builds FPGA bitstreams:
> 
> https://github.com/topic-embedded-products/meta-topic/blob/master/recipes-bsp/fpga/fpga-image.inc
> 
> Now you can have multiple recipes using it, and as such, it seemed a good idea 
> to add these lines to that recipe:
> 
> +ALTERNATIVE_${PN} = "fpga.bin bitstreams"
> +ALTERNATIVE_LINK_NAME[fpga.bin] = "${datadir}/fpga.bin"
> +ALTERNATIVE_TARGET[fpga.bin] = "${datadir}/fpga.bin"
> +ALTERNATIVE_LINK_NAME[bitstreams] = "${datadir}/bitstreams"
> +ALTERNATIVE_TARGET[bitstreams] = "${datadir}/bitstreams"
> 
> 
> This still resulted in staging conflicts.

This isn't surprising since update-alternatives only works for target
systems. It is not designed for operating on the sysroot.

> But looking at the contents of the fake packages, the fpga.bin has been 
> renamed by alternatives (as expected), and the symlink will be created after 
> installing, so how come I still get this?

The "staging" code uses the output of do_install directly and does
different things to the packaging code path. We've never had someone
with this problem before. Binaries in *bindir only get installed into
the sysroot in the -native case.

I appreciate that tells you why it doesn't work and not how to fix it
but hopefully that helps a bit.

Cheers,

Richard