Re: [Qemu-devel] updating to a u-boot without the case-sensitive filename clash

[Michael Roth]

Quoting Richard Henderson (2017-10-10 11:32:22)
> On 10/10/2017 07:22 AM, Peter Maydell wrote:
> > I can see a couple of options:
> >  (1) wait for next u-boot release (scheduled for Nov 13, 2017),
> >      and move to that
> >      [downsides: would be in the middle of QEMU's own release cycle,
> >       pretty late to fix any problems with the new version;
> >       rather a big change to put into stable]
> >  (2) move to u-boot current head-of-unstable
> >      [downsides: would mean running some random git commit version,
> >       also not really very suitable for stable]
> 
> It's always difficult to sync the release cycles of disjoint projects.
> 
> You had nothing particularly good to say about using a non-released u-boot, so
> really you have two options:
> 
>   (a) Update u-boot for 2.12 and not 2.11,
>   (b) Track u-boot during its release process, noticing and reporting 
> problems,
>       and updating to the final release when it appears.  If you go this 
> route,
>       you may well have to slip our release if theirs slips.
> 
> The second option is not particularly appealing.
> 
> Is there another possibility in which we split the packaging to cope with the
> current u-boot?  Normally no one builds u-boot; we simply package it for
> licensing.  If the packaging were in two parts, one could unpack the first 
> part
> only and not encounter the problem.

Would something like this be sufficient?

diff --git a/scripts/make-release b/scripts/make-release
index fa6323fda8..96c21e7a74 100755
--- a/scripts/make-release
+++ b/scripts/make-release
@@ -20,6 +20,7 @@ git checkout "v${version}"
 git submodule update --init
 (cd roms/seabios && git describe --tags --long --dirty > .version)
 rm -rf .git roms/*/.git dtc/.git pixman/.git
+tar cfj roms/u-boot.tar.bz2 roms/u-boot && rm -rf roms/u-boot
 popd
 tar cfj ${destination}.tar.bz2 ${destination}
 rm -rf ${destination}

And then we can optionally just revert it once we move to a fixed
u-boot? Although we'd need to take care in that case to make sure
we don't use the wrong version of make-release for a particular
point release.

> 
> 
> r~
>