| Summary: | Github Mirror does not work if SRC_URI contains downloadfilename | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] BitBake | Reporter: | Quirin Gylstorff <quirin.gylstorff> |
| Component: | bitbake | Assignee: | Ross Burton <ross.burton> |
| Status: | NEW --- | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium | CC: | pavel, poky.bs.watcher, poky.watcher, randy.macleod, yoann.congal |
| Version: | 4.2 | ||
| Target Milestone: | 5.99 | ||
| Hardware: | All | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | Yes (doc changes required) | |
|
Description
Quirin Gylstorff
2023-05-24 13:50:36 UTC
I'm not entirely sure what you mean by a "Github mirror". I presume you mean an arbitrary source mirror. There's definitely two conflicting use-cases here. The first is people that use a fully populated DL_DIR as a source mirror. This is a documented use case and a source mirror is expected to have a specific structure, for example git repositories can be exposed as tarballs with a specific structure and name. So in this case a source mirror isn't an arbitrary URL, it's specifically a bitbake-compatible source mirror. The second use-case is "the upstream server is bad, here is an alternative". We use this in oe-core, for example the Debian archive URLs have mirror entries which use snapshot.debian.org to handle tarballs which are purged from the archive. The problem is that these two use-cases have different semantics: in the first the downloadfilename in DL_DIR becomes the name in the mirror. In the latter, the real name not the downloadfilename is expected. It's not really feasible to support both usecase fully as they're contradictory. I suspect primarily supporting the first use case and the latter mostly works will be the right thing to do. Our use case would be the second where the upstream server is not reachable so take an alternative. We did not find any documentation which indicated that we have the current behavior, therefore we were not sure which is the correct. Could the documentation adapted? (In reply to Quirin Gylstorff from comment #2) > Our use case would be the second where the upstream server is not reachable > so take an alternative. > > We did not find any documentation which indicated that we have the current > behavior, therefore we were not sure which is the correct. > > Could the documentation adapted? I think you're looking for this doc: https://docs.yoctoproject.org/dev-manual/efficiently-fetching-sources.html . Implementations examples: https://low-level.wiki/mirrors/yocto_sources.html https://www.mndet.net/2018/12/28/yocto-mirrors.html Some of them may be outdated though An internal discussed solution was: If the fetcher does not find the `downloadfilename` on the mirror -> it tries the mirror with the original file name. Would this be an acceptable solution? |