| Summary: | devtool build does not cope with multiple SRC_URI in a recipe | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | worryelectric |
| Component: | devtools / tool chain | Assignee: | Julien Stephan <jstephan> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | chris.laplante, jstephan, meta.mr.watcher, meta.watcher, randy.macleod, richard.purdie, tgamblin, tom.isaacson |
| Version: | unspecified | ||
| Target Milestone: | 5.1 M2 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
|
Description
worryelectric
2023-07-15 14:46:06 UTC
It is a bug, the tool should either handle the case or warn the user that they need to handle the recipe manually. Hi worryelectric and Randy, I just send a fix for this https://lists.openembedded.org/g/openembedded-core/message/188335 can you check it? Julien Thanks Julien. (In reply to Julien Stephan from comment #2) > Hi worryelectric and Randy, > > I just send a fix for this > https://lists.openembedded.org/g/openembedded-core/message/188335 can you > check it? > > Julien This patch seems a bit too invasive. It just moves everything in WORKDIR (except for source-date-epoch, recipe-sysroot, recipe-sysroot-native) but I think we need a more surgical approach that actually considers whether things are part of SRC_URI. I am going to try to take a look. Hi Chris, agree with you, and as explained in this thread, this workaround is clearly not suitable as a fix: https://lists.openembedded.org/g/openembedded-core/message/188765 I didn't have time to look at it more deeply. Hi All, I've been thinking about this bug and how to reliably fix it and I would like to discuss it. The fix I sent (https://lists.openembedded.org/g/openembedded-core/message/188335) can be partially improved by using a devtool unpack tracer (see https://bugzilla.yoctoproject.org/show_bug.cgi?id=15294) but the main issue is: where secondary sources extracted in WORKDIR should be placed in devtool context? I can think of three possible solutions: 1: move them in WORKDIR (as my previous fix does it but get the correct list from the unpack tracer) 2: create a devtool specific workdir to put them. The specific workdir can be placed in build/workspace/workdir/<PN> (near sources/appends/recipes/). 3: modify bitbake itself to extract all SRC_URI's element in a subdir of WORKDIR (let's call it "sources") But each solution has its drawback: 1: we will end up with sources in 2 different places: main source and sources extracted in S in an isolated place and other sources in WORKDIR (which is not isolated and can be wiped out). Moreover, devtool can not be used to create patches for secondary sources. And we need to decide the strategy to copy secondary sources i.e what about if the package was already built and we do a devtool modify on it: should we erase old files? copy only if file doesn't exists? 2: it fits well with devtool idea to have sources in an isolated place. This can be easily implemented by setting WORKDIR in externalsrc.bbclass, BUT we will have B, T, D .. in build/workspace/workdir/<PN>, which may not be something we want.. 3: it would be much easier for devtool to handle all sources at once BUT that would require a LOT of changes in all recipes that expect sources to be extracted in WORKDIR. We will require a way to not allow recipes to extract sources in WORKDIR in the future, probably modify a lot of selftest, and this will impact a lot of external layers.. Also we need to take into consideration that devtool should (or not?) be able to produce patches for secondary sources... Maybe I am missing another strategy? Ultimately we may well end up moving to 3). I have tried something like it and it was extremely painful and requires changes in many places. As such it probably isn't an option right now. I was thinking of something along the lines of your original patch but using the tracer to remove the need to make assumptions about files. I think the idea here is to incrementally improve on things and that would seem in keeping with that... Quite often the solution becomes clearer when you actually try and implement it, I wouldn't push really hard on something which appears to be becoming very hard to implement. Hi Richard, all, I tried to implement the unpack tracer mechanism, but found a more easiest fix for this bug. I sent a new version of the series here: https://lists.openembedded.org/g/openembedded-core/message/194237. Let me know if that works for you as a fix. Cheers Julien poky commit facab170b60e521d69262e62f7d60ceb064ff3a2 |