Hello, -- Andrei Gherzan
On Thu, Jul 16, 2015 at 7:53 PM, Jon Szymaniak <[email protected]> wrote: > Hi all, > > >> > >> > So there is no support for depth clones until 2.5.0? I didn't really >> > understand. >> >> Well, shallow clones are supported but only for branch tips, which is >> not what we need. This feature for shallow cloning a specific revision >> is available only in git 2.5.0+. Also, this feature needs a server-side >> configuration option to be enabled, in order to work properly. >> >> Regards, >> Nikolay >> > > I'd argue that this whole issue with the whole meta-raspberrypi > firmware.inc download is more than just slow, inconvenient download. I've > left builds running all night (8+ hours on a 30Mib/s residential link) that > just hang on this, usually timing out. I initially thought it was just me, > but am hearing others confirm this as well. > > As such, I just wanted to continue this conversation. It sounds like git > fetch's --depth is the best option on the table, but has the issues Nikolay > has described. What are your thoughts on the following? > > (1) We create a git-native and build a version that supports this the > fetch depth? > > I suspect this could be made to work, but haven't dug into what > dependencies git may have and how that would play out on various LTS > distros. My knee-jerk is that has too high of a risk/benefit ration, given > that we're talking about 1 repo. > > (2) We update the git fetcher to check the git version and support a > depth= option if the git version is sufficient. If it is not, we spit out > a warning and fall back to the current behavior. > > Neither (1) nor (2) address Nikolay's point that --depth requires > server-side support. However, I'd argue this is something you'd be testing > and verifying when writing the recipe. Is this a reasonable assertion? How > likely is it that a server supporting this would suddenly be re-configured? > > (3) We request that the upstream maintainer of meta-raspberrypi use the > GitHub Release feature [a] to post a tarball of a known checksum at > somewhat regular intervals. I'm told by a few package maintainers that > while the tarballs that it generates for specific changesets are subject to > change, that the tarballs it autogenerates when using its Releases feature > do not. However, I have not confirmed this. If this is false, then one > can upload a tarball with known checksums to the release as an attachment; > I would be *shocked* if they touch your attachments. > > While (3) is a nice "not our problem" solution, I think (2) might have > some benefits for other recipes later. Any other ideas? > > Definitely 2 is the best opinion in my opinion too. I'm wondering if there is any work started in this direction.
-- _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
