Hi Nicolas,

I stumbled over this issue as well. Think of it this way, the package gets built in one environment and then it's built. Now ask to build it in another environment -- but it's built already, why do It again? Yes, in theory it would contain a different set of files / services / ... but it doesn't differentiate, because it's package A in both environments, not package A and package B. So in a sense, even though your (and my) expectations differed, I believe this works as intended.

I use to solve this issue by creating an A.inc file containing the shared stuff, a A.bb recipe building for the "default" environment, and A-XX.bb recpies for building the "XX" environment(s). Your A-XX package will be distinct from A. Now in your image setup, you can add A-XX to the XX sort of image. But keep in mind that your image is also just another recipe in the end. I believe building both in the same build dir with different distros again asks for surprises.

So, note that sharing the build dir still isn't a good idea. Richard said this is the use-case for the shared sstate so that multiple environments can share build results quickly and efficiently, and thus you wouldn't practically want a shared build dir (once you've setup sstate sharing), because you still get the benefits of not rebuilding unchanged packages, but don't step on your toes if you want to be odd one day and even another.

Best regards,

Martin Weber
Research & Development - Embedded Software Engineer

B&R Industrial Automation GmbH, B&R Straße 1, 5142 Eggelsberg, Austria, www.br-automation.com
Phone +43 7748 6586 - 0

-----Ursprüngliche Nachricht-----
Von: yocto@... <yocto@...> Im Auftrag von Nicolas Jeker via lists.yoctoproject.org
Gesendet: Dienstag, 12. Juli 2022 15:38
An: yocto@...
Betreff: [yocto] Switching between multiple DISTROs without "contamination"

BeSecure! This email comes from outside of ABB. Make sure you verify the sender before clicking any links or downloading/opening attachments.
If this email looks suspicious, report it by clicking 'Report Phishing' button in Outlook or raising a ticket on MyIS.


Hi all,

I'm currently using an additional layer and image to differentiate
between a release and development build (enabling NFS, SSH, root login,
etc.). To create a development build, I manually add the layer to
bblayers.conf. This works quite well, but feels a bit clumsy to
integrate into a CI/CD pipeline.

Per these past discussions here [1][2], I'm now trying to migrate to
multiple DISTROs, something like "mydistro" and "mydistro-dev".

While migrating some of the changes, I discovered that I run into
caching(?) issues. I have a recipe for an internal application and want
to include additional systemd service files in the development image.

What I did was this:

Added "application-dbg.service" to recipes-internal/application/files

Adapted application.bb recipe:

SRC_URI:append:mydistro-dev = " file://application-dbg.service"

do_install {
# ...snip...
# systemd service
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application.service
${D}${systemd_system_unitdir}
}

do_install:append:mydistro-dev() {
# debug systemd services
install -d ${D}${systemd_system_unitdir}
install -m 0644 ${WORKDIR}/application-dbg.service
${D}${systemd_system_unitdir}
}


When I run "DISTRO=mydistro-dev bitbake application" followed by
"DISTRO=mydistro bitbake application", the debug service file is still
present in the package. This seems to be caused by the "image"
directory in the recipe WORKDIR not being cleaned between subsequent
do_install runs. Is this expected behaviour? What's the best solution?

Kind regards,
Nicolas

[1]:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fyocto%2FCAH9dsRiArf_9GgQS4hCg5%3DJ_Jk6cd3eiGaOiQd788%2BiSLTuU%2Bg%40mail.gmail.com%2F&;data=05%7C01%7Cmartin.weber%40br-automation.com%7Cb4c2ffc9851847b6d7c208da640bb064%7C372ee9e09ce04033a64ac07073a91ecd%7C0%7C0%7C637932298663056785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=STA1V1w3ExlYrXkoYb7DDtkAWlkAeKhtFAkjjkUlsoQ%3D&amp;reserved=0
[2]:
https://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Flore.kernel.org%2Fyocto%2FVI1PR0602MB3549F83AC93A53785DE48677D3FD9%40VI1PR0602MB3549.eurprd06.prod.outlook.com%2F&;data=05%7C01%7Cmartin.weber%40br-automation.com%7Cb4c2ffc9851847b6d7c208da640bb064%7C372ee9e09ce04033a64ac07073a91ecd%7C0%7C0%7C637932298663056785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=dT4DkNsm0f0L%2BrCgF7f1Q8XBAN1j2bLYZ0%2FkbKr6nuo%3D&amp;reserved=0