On 28/05/2025 10:45 am, Anthony PERARD wrote:
> On Tue, May 27, 2025 at 04:24:57PM +0100, Andrew Cooper wrote:
>> On 27/05/2025 4:19 pm, Marek Marczykowski-Górecki wrote:
>>> On Tue, May 27, 2025 at 04:01:34PM +0200, Anthony PERARD wrote:
>>>> On Thu, May 22, 2025 at 06:36:39PM +0100, Andrew Cooper wrote:
>>>>> For Qubes, this requires switching from sh to bash.
>>>>>
>>>>> This reduces the number of times the target filename needs to be written
>>>>> to 1.
>>>>>
>>>>> Expand the comment to explain the concatination constraints.
>>>> Isn't the correct spelling "concatenation"? Same for the two comments.
>>>>
>>>>> No functional change.
>>>>>
>>>>> Signed-off-by: Andrew Cooper <andrew.coop...@citrix.com>
>>>>> ---
>>>>> I would like to find a slightly nicer way of conditional parts, but
>>>>> nothing
>>>>> comes to mind.
>>>> Well, one way I can think of is having a new variable which can carry
>>>> the rootfs part associated with a particular test, then that variable
>>>> can be updated at the time we configure for that test. Something like:
>>>>
>>>> # init
>>>> declare -a append_rootfs_part
>>>> # or append_rootfs_part=() is probably fine too.
>>>>
>>>> case $test in
>>>> argo)
>>>> append_rootfs_part+=(argo.cpio.gz)
>>>> # ... other test configuration
>>>> ;;
>>>> esac
>>>>
>>>> # Dom0 rootfs
>>>> parts=(
>>>> rootfs.cpio.gz
>>>> xen-tools.cpio.gz
>>>> "${append_rootfs_part[@]}"
>>>> )
>>>>
>>>> And that should works fine, even if there isn't any extra rootfs part.
>>> That would work for compressed parts, but not for uncompressed - which
>>> need to come before all compressed. But maybe there could be two arrays
>>> - one for uncompressed and another for compressed? Then, each could be
>>> extended anywhere, without messing the order.
> You could use "${append_rootfs_part:#*.gz}" and
> "${(M)append_rootfs_part:#*.gz}" to grab the uncompressed part then the
> compressed part... on zsh :-). But something similar could be codded in
> bash. But I guess two variables will be more acceptable.
I believe there's a restriction that only one type of compression can be
used, but I don't particularly fancy tying it to gz specifically.
Something else to look at in some copious free time is .xz or so. For
test-artefacts its surely a size win, but whether it's better overall
depends on whether using xz in this script doesn't undo the
optimisations we've been trying. Once this series is in, we're down to
a handful of tiny text files, so I expect it to be in the noise.
>> Hmm, two might work, but they surely need to not be quoted when forming
>> parts=(), or having multiple entries will go wrong on the eventual cat
>> command line.
> The double quote are needed!
Yes, sorry. That was a stupid suggestion of mine. I really ought to
know how "$@" works by now...
~Andrew
