[Buildroot] Per-package download folders and Git caching

[Yann E. MORIN <yann.morin.1998@free.fr>]

Arnout, All,

On 2018-04-03 22:44 +0200, Arnout Vandecappelle spake thusly:
> On 03-04-18 19:49, Yann E. MORIN wrote:
> > Peter, All,
> > 
> > On 2018-04-03 18:49 +0200, Peter Korsgaard spake thusly:
> >>>>>>> "Yann" == Yann E MORIN <yann.morin.1998@free.fr> writes:
> >>  > Should we do a cp if ln fails, then?
> >> That sounds like a sensible fallback, yes.
> > 
> > I was about to do so, but then we're back to a situation where we have
> > to guarantee the atomicity.
> > 
> > This is currently possible, because the dl-wrapper now runs under flock.
> > But we are going to optimise the locking with a more fine-grained
> > solution soonish.
> > 
> > To be noted: the current code is not atomic-safe either, because we do
> > have a TOCTTOU situation...
> > 
> > So, we'll have to again play tricks with atomicity...
> > 
> > We can't use flock again, because the destination directory is already
> > locked, and there is not destination file to lock to start with...
> > 
> > So, maybe the full solution will in fact to really implement the more
> > fine-grained solution... I'll see to it.
> 
>  Note that for the specific case I mentioned (hardlinks may not work over samba
> or VM shares), flock will fail as well...

Wait... So you're saying that we borked a working situation for a certain
class of users, now? Damn... :-/

And why would flock fail on those (curious)?

>  Maybe we should just wait until someone complains so they can test whatever
> solution we come up with.

In the end, yes, probably...

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'