From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6488313435861811200 X-Received: by 10.80.244.178 with SMTP id s47mr5190977edm.6.1511252434580; Tue, 21 Nov 2017 00:20:34 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.170.48 with SMTP id o45ls336911edc.3.gmail; Tue, 21 Nov 2017 00:20:34 -0800 (PST) X-Google-Smtp-Source: AGs4zMZd6l49uRzmmv37YVE2hCvVs97bjY8TZpGbPLMUNZ1kPCRVFKnSNV7ImkivLOuEYsgZMhg2 X-Received: by 10.80.203.138 with SMTP id k10mr2483312edi.5.1511252434114; Tue, 21 Nov 2017 00:20:34 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1511252434; cv=none; d=google.com; s=arc-20160816; b=0AelcTZZfZvdFR6XR0IcEiObnbPGE1wUr6qHcKWJJ6U+zh57xg/IFPrPkpZ91Yz8hi WsmSRTrhIVoZ/7m0Oz/rlg0XjxPz0qadvb8efDv+ihm0nsi5I1V7FgROtXeHBTjesljL A8OK9Cog+of9g+14ksD7dpoF49G9Y7DedUJFnmk2F+sqJria4b87gjAYRR+Z+lWNZpRg +Ht5//a9daXUB0AXDNLURYxgt8uJ24zytc+/HOvvmss5H0pupSLA8Q0Xb+Hl5l9PnUEJ oVj0VPZuUGtYqnZYszB0OB7E3YyL4ZIpRbHh3LnezV1PBFgGoclUVZJCgiUnkRUDaM89 8H5Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:arc-authentication-results; bh=GMstYcH6l0v06QHCzy06nhpYPrmQRrreRp2X07jt1Fg=; b=WOObsKAx5BtBBEge79oG6g8byn7z/dq+UC+ukm0XCL8mxFjDY3P73L97jVVDsj85kK F9/bmuq7Pu1TZkax55P9nESqxcE2nwxDTAXsPgYY4ZjbBsjFOQluN+gwcvRx4AW+c91z YJtA3a9hWhltsd9lF9OIC/NxXQheaQlEVa8r1DIKnQbkue1lStlSWWKLsiDmz2jbTeSA /feXLAu1ZhWeMxKfEYuwfZ+t10cVF5xM5OZ3lTuA2tmf3J1O655s9WJFkv+NCRHP5Nxk XEXvYgouqV+C0PWe6gDT1vMN7z+OvtQKXwhFix8O4MrnPIV3vB9jPvk9ZqrEVzfj41rY uf6Q== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from goliath.siemens.de (goliath.siemens.de. [192.35.17.28]) by gmr-mx.google.com with ESMTPS id a67si1020904edf.3.2017.11.21.00.20.33 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 21 Nov 2017 00:20:34 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) client-ip=192.35.17.28; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.28 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail2.siemens.de (mail2.siemens.de [139.25.208.11]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id vAL8KXkK008760 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Tue, 21 Nov 2017 09:20:33 +0100 Received: from md1em3qc ([139.25.68.40]) by mail2.siemens.de (8.15.2/8.15.2) with ESMTP id vAL8KXUV027128; Tue, 21 Nov 2017 09:20:33 +0100 Date: Tue, 21 Nov 2017 09:20:50 +0100 From: Henning Schild To: Alexander Smirnov Cc: Subject: Re: [PATCH] Map git objects to buildchroot Message-ID: <20171121092050.1d9adec7@md1em3qc> In-Reply-To: References: <20171120103728.08714150@md1em3qc> <20171120150641.9645-1-asmirnov@ilbers.de> <20171120163216.494df210@md1em3qc> X-Mailer: Claws Mail 3.13.2 (GTK+ 2.24.31; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-TUID: KluSn1LxAO1v Am Mon, 20 Nov 2017 18:54:23 +0300 schrieb Alexander Smirnov : > On 11/20/2017 06:32 PM, Henning Schild wrote: > > Am Mon, 20 Nov 2017 18:06:41 +0300 > > schrieb Alexander Smirnov : > > > >> Hi Christian, > >> > >> The patch above has 2 major issues: > >> > >> 1. It mounts ${GITDIR} to buildchroot during package building. This > >> variable is static, so it's the same for each recipe. This means > >> that if several packages are building in parallel, the folder > >> ${BUILDCHROOT_DIR}/${GITDIR} could be mounted/unmounted while there > >> is active I/O operation by another package. To be honest, I don't > >> know what could happen, but believe in worst case. > > > > True, that must not happen! > > > >> 2. Using host configuration in buildchroot could lead to some > >> problems. Lets consider the following example: > >> - User override ${DL_DIR} to point it to local cache, let's > >> say: /home/builder/XXX > >> - Isar uses the following path to build package > >> YYY: /home/builder/YYY > >> - If XXX equals YYY, you will probably experience some problems, > >> because your source tree will be overriden by incorect mount. > >> > >> So I'd see the more generic solution like patch below: > >> > >> 8<-- > >> > >> dpkg-base: Map git objects to buildchroot > >> > >> This patch mounts git repository to buildchroot into the respective > >> folder: > >> > >> /git/$REPO_NAME > >> > >> Also it updates git alternative to correctly point to objects in > >> buildchroot. > >> > >> Signed-off-by: Alexander Smirnov > >> --- > >> meta/classes/dpkg-base.bbclass | 13 +++++++++++++ > >> 1 file changed, 13 insertions(+) > >> > >> diff --git a/meta/classes/dpkg-base.bbclass > >> b/meta/classes/dpkg-base.bbclass index 35af6d5..147cfce 100644 > >> --- a/meta/classes/dpkg-base.bbclass > >> +++ b/meta/classes/dpkg-base.bbclass > >> @@ -19,12 +19,25 @@ dpkg_runbuild() { > >> > >> # Wrap the function dpkg_runbuild with the bind mount for > >> buildroot do_build() { > >> + if [ -d ${WORKDIR}/git/.git ]; then > >> + OBJ_PATH=$(cat > >> ${WORKDIR}/git/.git/objects/info/alternates) > >> + REPO_PATH=$(dirname $OBJ_PATH) > >> + REPO_NAME=$(basename $REPO_PATH) > >> + sudo mkdir -p ${BUILDCHROOT_DIR}/git/$REPO_NAME > >> + sudo mount --bind $REPO_PATH > >> ${BUILDCHROOT_DIR}/git/$REPO_NAME > >> + echo "/git/$REPO_NAME/objects" > > >> ${WORKDIR}/git/.git/objects/info/alternates > >> + fi > >> + > >> mkdir -p ${BUILDROOT} > >> sudo mount --bind ${WORKDIR} ${BUILDROOT} > >> _do_build_cleanup() { > >> ret=$? > >> sudo umount ${BUILDROOT} 2>/dev/null || true > >> sudo rmdir ${BUILDROOT} 2>/dev/null || true > >> + if [ -d ${WORKDIR}/git/.git ]; then > >> + sudo umount ${BUILDCHROOT_DIR}/git/$REPO_NAME > >> + sudo rm -rf ${BUILDCHROOT_DIR}/git/$REPO_NAME > >> + fi > >> (exit $ret) || bb_exit_handler > >> } > >> trap '_do_build_cleanup' EXIT > > > > I would not do this either. There should be one mount in > > buildchroot.bb and one umount. Additional umounts could be allowed > > in exception handlers, in case they can not call out to functions > > from buildchroot. > > Sorry, didn't get your idea regarding one mount buildchroot.bb, what > do you mean? There should be one mount done from buildchroot.bb before all the do_builds of package recipes start. And that should get umounted after the last do_build is done. > BTW: we always have option to clone git repository to workspace by > running in ${WORKDIR}/git: > > $ git repack -a > > in do_build() task. With this, no extra mount/umount logic is needed. That sounds promising. But i would only do that if git is actually the only download-tool that works with such "symlinks". If it is not the whole dl-dir should get mounted, not just the git-subdir. > We could consider this behavior for source 3.0 packages only by using > some flag in recipe. I think that is something we can just do in any case. A flag would just complicate things. Henning > Alex