[Pkg-xen-devel] [PATCH 01/12] Revert "debian/rules: Do not try to move EFI binaries on armhf"

[Ian Jackson]

Elliott Mitchell writes ("[PATCH 01/12] Revert "debian/rules: Do not try to move EFI binaries on armhf""):
> If EFI isn't being built the files simply won't be there and the line
> accomplishes nothing.  If EFI is added to a new platform this adds an
> extra spot which breaks.

Hi.  Thanks for all this work.  I'm reviewing your patches.
(FYI I am involved both in Xen in Debian, and am also upstream.[1])

> diff --git a/debian/rules b/debian/rules
> index 543c735f3e..cd90e27038 100755
> --- a/debian/rules
> +++ b/debian/rules
> @@ -224,10 +224,7 @@ override_dh_auto_install: $(TEMPLATED_FILES)
>  		-C tools/firmware install-shim
>  	:
>  	@# Inexplicably, upstream puts the efi binares in usr/lib64
> -	case $(flavour) in \
> -		armhf) ;; \
> -		*) mv $t/usr/lib64/efi/* $t/boot/. ;; \
> -	esac
> +	mv $t/usr/lib64/efi/* $t/boot/.
>  	:

This looks to me like it will fail if the files do not exist.  The
case was a way to work around this problem.  That is, I think the
shell will execute the command with literally a `*' and then mv will
complain.

We need a rune which doesn't fail if the file is absent.  But it
*should* fail if the file exists but the rename fails.
(Maybe we could do this with some debhelper thing instead.)

Ian.

[1] Full disclosure: I an employee of Citrix and paid to work on Xen.

-- 
Ian Jackson <ijackson at chiark.greenend.org.uk>   These opinions are my own.  

Pronouns: they/he.  If I emailed you from @fyvzl.net or @evade.org.uk,
that is a private address which bypasses my fierce spamfilter.