Camera, sensors: switch to main protobuf version

[lumag]

Upgrade sensors and camera binaries to the version which is linked against protobuf version from meta-oe.

This is an alternative to #1571, keeping the protobuf-camx name for the sake of simplifying handling the of binary vs meta-oe handling in future. When the situation repeats there would be no need to switch between protobuf and protobuf-camx anymore.

[lumag]

cc @gkhose-qipl

[quaresmajose]

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

[lumag]

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

If you take a look at #1491, we had to vendor in the version from meta-oe and change all camera / sensors recipes to use protobuf-camx. With the proposed approach in place, the only change would be to change the protobuf-camx recipe from the empty stub to the full-featured protobuf implementation and back.

[quaresmajose]

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

If you take a look at #1491, we had to vendor in the version from meta-oe and change all camera / sensors recipes to use protobuf-camx. With the proposed approach in place, the only change would be to change the protobuf-camx recipe from the empty stub to the full-featured protobuf implementation and back.

I think this will not work because your current protobuf-camx is empty. Therefore, it will not provide the dependencies that are necessary for its users recipes.

It seems to me that what you want to do would be easier using a virtual name with PROVIDES/RPROVIDES and flip it by the the backport from meta-oe when it breaks next time:

cat <'_EOF_' >> dynamic-layers/openembedded-layer/recipes-support/protobuf/protobuf_%.bbappend
PNCAMX:qcom = "${PN}-camx"
PROVIDES:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
RPROVIDES:${PN}:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
_EOF_

[lumag]

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

If you take a look at #1491, we had to vendor in the version from meta-oe and change all camera / sensors recipes to use protobuf-camx. With the proposed approach in place, the only change would be to change the protobuf-camx recipe from the empty stub to the full-featured protobuf implementation and back.

I think this will not work because your current protobuf-camx is empty. Therefore, it will not provide the dependencies that are necessary for its users recipes.

The (empty) protobuf-camx recipe will pull in protobuf recipe, adding protobuf library to the sysroot. Then, when building packages, OE will correctly identify packages providing those libs and add them to RDEPENDS.

It seems to me that what you want to do would be easier using a virtual name with PROVIDES/RPROVIDES and flip it by the the backport from meta-oe when it breaks next time:

cat <'_EOF_' >> dynamic-layers/openembedded-layer/recipes-support/protobuf/protobuf_%.bbappend
PNCAMX:qcom = "${PN}-camx"
PROVIDES:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
RPROVIDES:${PN}:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
_EOF_

[quaresmajose]

The (empty) protobuf-camx recipe will pull in protobuf recipe, adding protobuf library to the sysroot. Then, when building packages, OE will correctly identify packages providing those libs and add them to RDEPENDS.

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

If you take a look at #1491, we had to vendor in the version from meta-oe and change all camera / sensors recipes to use protobuf-camx. With the proposed approach in place, the only change would be to change the protobuf-camx recipe from the empty stub to the full-featured protobuf implementation and back.

I think this will not work because your current protobuf-camx is empty. Therefore, it will not provide the dependencies that are necessary for its users recipes.

The (empty) protobuf-camx recipe will pull in protobuf recipe, adding protobuf library to the sysroot. Then, when building packages, OE will correctly identify packages providing those libs and add them to RDEPENDS.

If you say that the OE will correctly provide the RDEPENDS and will not use the protobuf-camx on that, then I take back what I said.

It seems to me that what you want to do would be easier using a virtual name with PROVIDES/RPROVIDES and flip it by the the backport from meta-oe when it breaks next time:

cat <'_EOF_' >> dynamic-layers/openembedded-layer/recipes-support/protobuf/protobuf_%.bbappend
PNCAMX:qcom = "${PN}-camx"
PROVIDES:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
RPROVIDES:${PN}:qcom += "${PNCAMX}-compiler ${PNCAMX}-lite"
_EOF_

In any case, I still think it's more correct to do this with PROVIDES/RPROVIDES.

[koenkooi]

The (empty) protobuf-camx recipe will pull in protobuf recipe, adding protobuf library to the sysroot. Then, when building packages, OE will correctly identify packages providing those libs and add them to RDEPENDS.

The problem that led to the exchange between protobuf-camx and protobuf was the library soname versions. I don't see how the proposed solution solves the problem when it comes again without copy the downgraded recipe from meta-oe. Can you explain it please?

If you take a look at #1491, we had to vendor in the version from meta-oe and change all camera / sensors recipes to use protobuf-camx. With the proposed approach in place, the only change would be to change the protobuf-camx recipe from the empty stub to the full-featured protobuf implementation and back.

I think this will not work because your current protobuf-camx is empty. Therefore, it will not provide the dependencies that are necessary for its users recipes.

The (empty) protobuf-camx recipe will pull in protobuf recipe, adding protobuf library to the sysroot. Then, when building packages, OE will correctly identify packages providing those libs and add them to RDEPENDS.

If you say that the OE will correctly provide the RDEPENDS and will not use the protobuf-camx on that, then I take back what I said.

DEPENDS are transitive, so the upstream protobuf libraries will be in sysroot, as @lumag pointed out above. This in turn enables the OE shlib dependency solver to see both the library and its provider to generate RDEPENDS correctly. What you list in DEPENDS has no bearing on RDEPENDS, the shlib code only looks at the sysroot.
Take glibc as an example, it's rarely listed in DEPENDS, but the shlib solver does add it to all packages needing it since it will be in the sysroot thanks to other recipes pulling it in.

What you manually list in RDEPENDS does matter, but that's not the case here.

[quaresmajose]

Lets sopose another component/package will need the protobuf-compiler on the target and he needs to add it to his RDEPENDS. How should he do this? Should he use RDEPENDS${PN} = "protobuf-compiler" or RDEPENDS${PN} = "protobuf-camx-compiler"? or none of them will work?

[lumag]

Lets sopose another component/package will need the protobuf-compiler on the target and he needs to add it to his RDEPENDS. How should he do this? Should he use RDEPENDS${PN} = "protobuf-compiler" or RDEPENDS${PN} = "protobuf-camx-compiler"? or none of them will work?

Just DEPENDS += "protobuf-camx" and then link against the protobuf libs as usual.

[quaresmajose]

Lets sopose another component/package will need the protobuf-compiler on the target and he needs to add it to his RDEPENDS. How should he do this? Should he use RDEPENDS${PN} = "protobuf-compiler" or RDEPENDS${PN} = "protobuf-camx-compiler"? or none of them will work?

Just DEPENDS += "protobuf-camx" and then link against the protobuf libs as usual.

The protobuf-compiler is a binary, so no linked. My question is, if it will be necessary on the target image and not at build time. In this case, you need to provide the RDEPENDS manually.

[lumag]

Lets sopose another component/package will need the protobuf-compiler on the target and he needs to add it to his RDEPENDS. How should he do this? Should he use RDEPENDS${PN} = "protobuf-compiler" or RDEPENDS${PN} = "protobuf-camx-compiler"? or none of them will work?

Just DEPENDS += "protobuf-camx" and then link against the protobuf libs as usual.

The protobuf-compiler is a binary, so no linked. My question is, if it will be necessary on the target image and not at build time. In this case, you need to provide the RDEPENDS manually.

Ah, I see your point now.

[lumag]

Lets sopose another component/package will need the protobuf-compiler on the target and he needs to add it to his RDEPENDS. How should he do this? Should he use RDEPENDS${PN} = "protobuf-compiler" or RDEPENDS${PN} = "protobuf-camx-compiler"? or none of them will work?

Just DEPENDS += "protobuf-camx" and then link against the protobuf libs as usual.

The protobuf-compiler is a binary, so no linked. My question is, if it will be necessary on the target image and not at build time. In this case, you need to provide the RDEPENDS manually.

Ah, I see your point now.

Fixed now.