From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-7.3 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED,USER_AGENT_SANE_1 autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 18D5DC433E0 for ; Mon, 22 Mar 2021 16:54:16 +0000 (UTC) Received: from lists.xenproject.org (lists.xenproject.org [192.237.175.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPS id CB68461990 for ; Mon, 22 Mar 2021 16:54:15 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org CB68461990 Authentication-Results: mail.kernel.org; dmarc=fail (p=quarantine dis=none) header.from=suse.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=xen-devel-bounces@lists.xenproject.org Received: from list by lists.xenproject.org with outflank-mailman.100383.191216 (Exim 4.92) (envelope-from ) id 1lONoM-0006uo-OC; Mon, 22 Mar 2021 16:53:50 +0000 X-Outflank-Mailman: Message body and most headers restored to incoming version Received: by outflank-mailman (output) from mailman id 100383.191216; Mon, 22 Mar 2021 16:53:50 +0000 Received: from localhost ([127.0.0.1] helo=lists.xenproject.org) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lONoM-0006uh-LD; Mon, 22 Mar 2021 16:53:50 +0000 Received: by outflank-mailman (input) for mailman id 100383; Mon, 22 Mar 2021 16:53:48 +0000 Received: from all-amaz-eas1.inumbo.com ([34.197.232.57] helo=us1-amaz-eas2.inumbo.com) by lists.xenproject.org with esmtp (Exim 4.92) (envelope-from ) id 1lONoK-0006uc-Sl for xen-devel@lists.xenproject.org; Mon, 22 Mar 2021 16:53:48 +0000 Received: from mx2.suse.de (unknown [195.135.220.15]) by us1-amaz-eas2.inumbo.com (Halon) with ESMTPS id b8105d54-07e7-42ae-afce-23d3707ddf8f; Mon, 22 Mar 2021 16:53:47 +0000 (UTC) Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id 8727DAF0D; Mon, 22 Mar 2021 16:53:46 +0000 (UTC) X-BeenThere: xen-devel@lists.xenproject.org List-Id: Xen developer discussion List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xenproject.org Precedence: list Sender: "Xen-devel" X-Inumbo-ID: b8105d54-07e7-42ae-afce-23d3707ddf8f X-Virus-Scanned: by amavisd-new at test-mx.suse.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suse.com; s=susede1; t=1616432026; h=from:from:reply-to:date:date:message-id:message-id:to:to:cc:cc: mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=rPR682WIHuCagi0j74zp3+OiB5sB38u/YRtUa9hb4Yc=; b=JRG4iHR+5f5tTJQrZbGK34f7xSbmVTD7gJW0O7Lzyhr461febRpB1WIQUfw+IQu1n+5Jxz QOb5EKjs6OJ+ZdgFcH0zjeWp84T8/9jQX0inEDExgYw9u8OImCik/rFgviWYOlZxqPya/Z b2k6ZRTLs+UIAOOsUvgV783cXpPzHhw= Subject: Re: [PATCH] xen: Create EFI_VENDOR directory To: Jason Andryuk Cc: Andrew Cooper , George Dunlap , Ian Jackson , Julien Grall , Stefano Stabellini , Wei Liu , xen-devel References: <20210322133301.11308-1-jandryuk@gmail.com> From: Jan Beulich Message-ID: <23556ca9-86f4-854f-5178-6fb927166245@suse.com> Date: Mon, 22 Mar 2021 17:53:45 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit On 22.03.2021 16:36, Jason Andryuk wrote: > On Mon, Mar 22, 2021 at 11:15 AM Jan Beulich wrote: >> >> On 22.03.2021 15:59, Andrew Cooper wrote: >>> On 22/03/2021 14:52, Jan Beulich wrote: >>>> On 22.03.2021 14:33, Jason Andryuk wrote: >>>>> make install-xen fails when EFI_VENDOR is set (=fedora) with: >>>>> install: cannot create regular file '/home/user/xen/dist/install/boot/efi/efi/fedora/xen-4.15.0-rc.efi': No such file or directory >>>>> >>>>> Create the EFI_VENDOR directory so xen.efi can be installed within. >>>>> >>>>> This removes the need for Fedora and Qubes xen.spec files to manually >>>>> create the directory in advance. >>>> While I'm not strictly against, I'd like to point out that it was >>>> deliberate to not create this directory here. I also didn't expect >>>> anyone's xen.spec to do so. Instead I'd expect the distro to create >>>> it during OS installation. If this was a bad assumption, I'd prefer >>>> if the commit message here could point out why such an expectation >>>> won't hold in general. > > I didn't write this for an rpm xen.spec - I just cross referenced out > of curiosity. > >>> This reasoning is broken for anything other `make install DESTDIR=/` on >>> a live system. >>> >>> It is incompatible with how RPM, deb, etc packages work. >> >> I'm afraid I don't understand, for both of your statements. If distro >> installation put in place the designated directory, there wouldn't be >> any live system lacking it, and there wouldn't be any concern in the >> packaging of any software. >> >> To take a perhaps too extreme example - packages typically expect e.g. >> /usr to exist as well, don't they? > > But you have to install -d ${D}/usr before install ${D}/usr/file, right? Sure, but I take it that about every package can rely on it to be there, and not have to take care of creating it. There ought to be an "owning" package for that directory, and that's the package responsible for creating it. The same would then go for wherever you want xen.efi to go. > It's a surprising sequence to: > 1) see 'EFI installation only partially done (EFI_VENDOR not set)' > 2) set EFI_VENDOR > 3) see xen.efi installation fail > > I was working on a fedora system, and I was using `make && sh > install.sh` to install (but be sure to `rm -r dist/install/var/run` > since otherwise that'll break booting). I wanted xen.efi to end up in > /boot/efi/EFI/fedora after running `sh install.sh`, and EFI_VENDOR > appeared to be the way to do it. Again, it was surprising to enable > an option and then have it break. Well - the thing is that according to my understanding you don't simply pick a directory name of your liking, but you use the one your distro uses. Otherwise I consider it quite likely that upon next re-building of the EFI partition your binary won't be put back. Jan