[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] updating to a u-boot without the case-sensitive filenam
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] updating to a u-boot without the case-sensitive filename clash |
Date: |
Tue, 10 Oct 2017 10:51:38 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 |
On 10/10/2017 10:43 AM, Michael Roth wrote:
> 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.
That seems very reasonable to me. It also avoids the problem that I would have
introduced wrt having two distribution tarballs.
r~