On Tue, 2020-09-22 at 16:40 -0400, Robert P. J. Day wrote: > Quoting "Robert P. J. Day" <[email protected]>: > > > Never had cause to dig into SSTATE_DUPWHITELIST until now, > > so a couple questions. (Side Note: This variable is not listed > > in the YP Reference Manual variable glossary -- should it be?) > > > > Ran across this as current project incorporates recipes > > grpc-python and python-grpcio, which is problematic as the > > latter is simply the renamed version of the former so, yeah, > > that's definitely going to generate a ton of file install > > conflicts. > > > > The solution selected (and, yes, I know this is tacky and > > gross and this should be fixed the right way) was to add > > the line: > > > > SSTATE_DUPWHITELIST = "/" > > > > to python-grpcio.inc, which *seemed* to fix the problem, > > until I started playing this morning to clarify what different > > variations of this solution would do. > > > > First oddity was that, after I added or deleted that line, > > it seemed it made no difference in the rebuild of the > > incorporating image, until I noticed this in > > sstate.bbclass: > > > > sstate_install[vardepsexclude] += "SSTATE_DUPWHITELIST ..." > > > > which suggests that the sstate doesn't check dependency > > based on SSTATE_DUPWHITELIST, so to get the change to kick in, > > I did a "bitbake -c cleanall ..." on those recipes first, > > and that seemed to do it. > > > > But even that showed some weirdly non-deterministic behaviour, > > as there seemed to be a difference based on which recipe I > > added that line to, and which recipe I cleaned. So the > > obvious question is, if I have two recipes that clash in > > terms of installed files like these two, does one add that > > line to either or both of the recipes? What does it mean to > > add it to only one, and if that happens (as it did here), > > how does that affect the eventual install? Does ordering then > > matter? > > > > In a general case, if I have, say, 5 recipes all of which > > clash in the same place, do I add that line to all 5 recipes? > > And if I don't, do I get undefined behaviour? > > Oh, wait, I think I misunderstood this variable entirely -- > it's not a per-recipe variable, is it? Its value represents the > combination over all recipes in the image, is that right? So > by adding the line: > > SSTATE_DUPWHITELIST = "/" > > I've effectively de-activated file conflict errors across the > entire rootfs and all recipes in the image, do I have that right?
You are totally misunderstanding what this variable does. It has nothing to do with images or rootfs. Its also definitely not per recipe. sstate has an overall view of any output 'deployed' in TMPDIR. For example the sstate of the do_package_write_ipk tasks deploys the ipks into DEPLOY_DIR_IPK. In a perfect world, no sstate should overwrite the sstate of anything else. In reality there are some corner cases where one set of sstate output may overwrite another set. An example would be the sdk-provides-dummy- target ipk/rpm files when multilib is enabled. This variable controls whether these overlapping sstate files should be allowed or whether they should be errors. Documenting it is a low priority as either you understand the sstate code internals and know how to use it or you probably shouldn't be changing it. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#50775): https://lists.yoctoproject.org/g/yocto/message/50775 Mute This Topic: https://lists.yoctoproject.org/mt/77021783/21656 Group Owner: [email protected] Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
