| Summary: | When using SRC_URI, `localpath` fetch fails on copying from `downloads` | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Pawel J Maciakowski <Pawel.J.Maciakowski> |
| Component: | bitbake | Assignee: | Unassigned <unassigned> |
| Status: | IN PROGRESS DESIGN --- | QA Contact: | |
| Severity: | minor | ||
| Priority: | Medium | CC: | poky.bs.watcher, poky.watcher, randy.macleod |
| Version: | 3.3.4 | ||
| Target Milestone: | 6.1 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
With this, I would propose to expose `localpath` as it is in the code but did not make it to documentation. I'm a bit concerned about adding a special case around localpath. It's usage within the bitbake fetchers is already fairly convoluted already and using it as a way to rename something like this is probably going to cause problems in the future. localpath isn't part of the publicly documented API partly for that reason, it behaves differently depending on the url type and would probably not work well for mirroring, in other words it is erratic API at best. I'd note that a special task doesn't need to be added, you could use a do_unpack postfunc to rename the file in WORKDIR. Your use case/requirement is a reasonable one, we somehow should have a way to be able to rename at unpack time as well as download time. The best solution might be to add a "downloadprefix" parameter, similar to "downloadfilename" but addressing your use case? I'd also note that any change will need tests adding to lib/bb/tests/fetch.py so that "bitbake-selftest bb.tests.fetch" can ensure this continue to work. The fetcher has so many corner cases, we need to ensure all valid usages have testcases. Thanks! Yeah, I have tried to find uses of `localpath` and failed. I feel like putting paths into `downloadfilename` would be confusing. So, `downloadprefix` would be great. Pawel, From the YP bug review, this seems like Richard has suggested an approach. Can you send a patch to the oe-core list? Sure, I will create a patch. This is my first contribution, so I need to familiarize myself with the process "in the meantime". Hi Pawel, That's excellent, thanks in advance. We do have a contributor guide with lots of info: https://docs.yoctoproject.org/contributor-guide/submit-changes.html#sending-the-patches-via-email and above and below that. You can send to yourself to do a first level check and if you like, you could send me a draft as well. ../Randy Sorry, I can't support this in the "near-term". I am unassigning myself so that someone can pick it up. |
Use case: `downloadfilename` only allows to change the name of the file, as it is seen in downloads and in build. For artifacts that have generic file names (e.g. `template.zip`), renaming to a temporary unique name would mean that a special task in build needs to be added to rename back to a name build expects. `localpath` seems like a good candidate, as it allows to specify a custom file name and path as well. For `template.zip` this means one can do `unique_folder/template.zip` and retrieve the artifact as `template.zip`. No additional tasks needed, all solved by SRC_URI. It turns out, that `localpath` in `lib/bb/fetch2/__init__.py` in `FetchMethod` is resolved correctly, checked for existence, and then passed to a branch that will copy it, but working directory for that command is changed and path can no longer be resolved failing the build with, e.g.: ``` cp: cannot stat 'unique_name/template.zip': No such file or directory ``` I would like to propose to prepend ${DL_DIR} to `file` using a condition `if "localpath" in urldata.parm`, once in the `if not unpack or not cmd:` conditional. For `yocto-3.3.4` that is `lib/bb/fetch2/__init__.py:1517`.