<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Oct 12, 2016 at 10:01 AM, Phil Blundell <span dir="ltr"><<a href="mailto:pb@pbcl.net" target="_blank">pb@pbcl.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3a0" class="a3s aXjCH m157b9d9b95a0881a">I just ran into an annoying problem with two recipes whose upstreams<br>
both use the same poor naming scheme for their downloadable tarballs<br>
which causes the sources to collide in DL_DIR. One of them is eudev,<br>
which has:<br>
<br>
SRC_URI = "<a href="https://github.com/gentoo/${BPN}/archive/v${PV}.tar.gz" rel="noreferrer" target="_blank">https://github.com/gentoo/${<wbr>BPN}/archive/v${PV}.tar.gz</a><br>
<br>
This shows up as a source checksum error when the second package finds<br>
what it thinks are its sources in DL_DIR, but of course they are not<br>
the files that it wanted.<br>
<br>
I couldn't immediately find any easy way to work around this<br>
difficulty. Setting "localpath=eudev_v{$PV}.tar.<wbr>gz" in eudev's SRC_URI<br>
looks superficially like it ought to do the right thing, but although<br>
this changes the location that the fetcher will search for the<br>
downloaded file it doesn't actually cause wget to put the file there so<br>
this doesn't work either.<br></div></blockquote><div><br></div><div>I think that’s just a bug.. The fetcher should fully obey the url parameters we support, so we should fix the wget fetcher to properly obey localpath.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div id=":3a0" class="a3s aXjCH m157b9d9b95a0881a">
I suppose I could define DL_DIR in terms of ${PN}, which would<br>
presumably fix this problem at the cost of causing all my previous<br>
downloads to be repeated. Or I could stop using eudev, or wait for one<br>
of the two packages to release a new version. :-) Any better<br>
suggestions?</div></blockquote></div><br>One option would be to change DL_DIR, but use PREMIRRORS for compatibility with existing DL_DIRs, i.e.:</div><div class="gmail_extra">DL_DIR_BASE = “${TOPDIR}/downloads”</div><div class="gmail_extra">DL_DIR = “${DL_DIR_BASE}/${BPN}”</div><div class="gmail_extra">PREMIRRORS_prepend = “file://.*/ file://${DL_DIR_BASE}/\n “</div><div class="gmail_extra"><br></div><div class="gmail_extra">or similar (untested).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Of course, this conflict will occur on a mirror too, so that’s a concern if you care about mirror population.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Long term, I’d like to see our DL_DIR as a more capable download cache. Download every file to a unique name based on its checksum, then link those into a ${BPN}-separated area with their real names. Then add a separate tool to populate a mirror from DL_DIR.</div><div class="gmail_extra">-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Christopher Larson<br>clarson at kergoth dot com<br>Founder - BitBake, OpenEmbedded, OpenZaurus<br>Maintainer - Tslib<br>Senior Software Engineer, Mentor Graphics</div>
</div></div>