From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7057122428766388224 X-Received: by 2002:a05:6512:3991:: with SMTP id j17mr20563163lfu.602.1643740888715; Tue, 01 Feb 2022 10:41:28 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a05:6512:22d1:: with SMTP id g17ls1127603lfu.2.gmail; Tue, 01 Feb 2022 10:41:27 -0800 (PST) X-Google-Smtp-Source: ABdhPJwmmCA3PUQwTdObILTauU0rbmqVpjLy0bpfscKpdkmyxl2DN2KrxRsrztGC+oVb9RHbRJJP X-Received: by 2002:a05:6512:220e:: with SMTP id h14mr19852291lfu.212.1643740887597; Tue, 01 Feb 2022 10:41:27 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643740887; cv=none; d=google.com; s=arc-20160816; b=PRgczZRh5S926xXOvTk+fHqgM26Goi/45tfbSIp07KbO4HK2sRBWLCCQf5DFIuKwlP PwZYcG8CjhnMwina7tqRIkSrwrxmuuKu8O9wIe8aUl7fjRUrvpX3w6xEhGhTIBfS4UFE ULUO0x9BQhqFtvRmfNAXPnb2TFZtNhKL+GFfthuCYfff6cYcHJ2iO2xRwkTLtReqttn0 +Ah3QhWgUCNh4mC2xelzOiifQmRSmLJpsZ4socCCS+I+zhAhFnWG63/w5RiiPCH46spM 1GSMqM3fnDp3emaBX1pERh7958lP9LFG3yixCx6moZp41XyH1wqTp01pV+CCw2PoY7vI GP5w== 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:date:subject:cc:to:from; bh=eDSeEzYswEiuc5RVOkAIiNQzXBrwu+B+uuHpxIWu5Kg=; b=yaDd/ZC+1KiABC87BUBqsvQF04ktnaWdLeOs8iqJqu/YMq95SL9aEKNIjLKIfQumyt 5yGM1ctjSBh8inUp6O38fV1anjzfnANsc1V32gBgmvmXbq1r3W9OTO9Vpf+j+xCP19g1 U1KGg8lvAMSWh3khhYlqdq71tZZxOtx9+B086AuMbZV2Xmv7hgGRgilfIbw/1Ktiyg7b u6x3ljE93Xd4eIjkw9DTlpVtavCK4ah1tGhZRf84eje25SElpb10hhwaEWTW9HVkli7E BpP97LYlYag1uKB5s1edQgrg/4+aWJe/xZJ4I25o1IgUNvpFjnHdXTQnm1BVn7XK17tm 8Zgw== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Return-Path: Received: from shymkent.ilbers.de (shymkent.ilbers.de. [85.214.156.166]) by gmr-mx.google.com with ESMTPS id l17si155766lje.5.2022.02.01.10.41.27 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Tue, 01 Feb 2022 10:41:27 -0800 (PST) Received-SPF: pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) client-ip=85.214.156.166; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of ubely@ilbers.de designates 85.214.156.166 as permitted sender) smtp.mailfrom=ubely@ilbers.de Received: from home.localnet (44-208-124-178-static.mgts.by [178.124.208.44] (may be forged)) (authenticated bits=0) by shymkent.ilbers.de (8.15.2/8.15.2/Debian-8) with ESMTPSA id 211IfKc8020358 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 1 Feb 2022 19:41:26 +0100 From: Uladzimir Bely To: isar-users@googlegroups.com Cc: Jan Kiszka Subject: Re: [PATCH v5 07/12] sbuild: support of shell exports from dpkg_runbuild_prepend Date: Tue, 01 Feb 2022 21:41:19 +0300 Message-ID: <3317197.LZWGnKmheA@home> In-Reply-To: <0e396fe1-889c-8c38-de5d-91274222b955@siemens.com> References: <20220201170038.5723-1-ubely@ilbers.de> <20220201170038.5723-8-ubely@ilbers.de> <0e396fe1-889c-8c38-de5d-91274222b955@siemens.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED autolearn=unavailable autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on shymkent.ilbers.de X-TUID: qxn4ExrjbLkb In the email from Tuesday, 1 February 2022 21:09:07 +03 user Jan Kiszka wrote: > On 01.02.22 18:00, Uladzimir Bely wrote: > > Many of recipes often use shell exports done in dpkg_run_prepend, so that > > this changed environment is used during build. > > > > While sbuild is performed in isolated environment, we need a way to > > pass these variables to it. This is done by storing environment before > > dpkg_runbuild (after prepare_build) and finding just before the actual > > build what was changed or added. > > > > Signed-off-by: Uladzimir Bely > > --- > > > > meta/classes/dpkg.bbclass | 18 ++++++++++++++++++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/meta/classes/dpkg.bbclass b/meta/classes/dpkg.bbclass > > index 66db7ec5..c252e9b3 100644 > > --- a/meta/classes/dpkg.bbclass > > +++ b/meta/classes/dpkg.bbclass > > @@ -29,12 +29,30 @@ do_install_builddeps[lockfiles] += > > "${REPO_ISAR_DIR}/isar.lock"> > > addtask devshell after do_install_builddeps > > > > +DPKG_PREBUILD_ENV_FILE="${WORKDIR}/dpkg_prebuild.env" > > + > > +do_prepare_build_append() { > > + env > ${DPKG_PREBUILD_ENV_FILE} > > +} > > + > > > > # Build package from sources using build script > > dpkg_runbuild() { > > > > E="${@ isar_export_proxies(d)}" > > E="${@ isar_export_ccache(d)}" > > export PARALLEL_MAKE="${PARALLEL_MAKE}" > > > > + env | while read -r line; do > > + # Filter the same lines > > + grep -q "^${line}" ${DPKG_PREBUILD_ENV_FILE} && continue > > + # Filter some standard variables > > + echo ${line} | grep -q "^HOME=" && continue > > + echo ${line} | grep -q "^PWD=" && continue > > + > > + var=$(echo "${line}" | cut -d '=' -f1) > > + value=$(echo "${line}" | cut -d '=' -f2-) > > + sbuild_export $var "$value" > > + done > > + > > > > profiles=$(grep "DEB_BUILD_PROFILES" ${SBUILD_CONFIG} | tail -n1 | > > cut -d "'" -f 4) if [ ${ISAR_CROSS_COMPILE} -eq 1 ]; then > > > > profiles="${profiles} cross nocheck" > > So, this basically decouples "Avoid using shell environment during the > build" and similar conversions downstream from this series, right? It's > indeed good to have a compat path now. > > However, what are the patterns we want to push? Avoiding exports? Then > we should probably warn here that this compat path should be avoided and > might be removed in the future. > > If we want to keep both, we can probably leave several recipes alone in > that other series. > > Jan You might be right. Current solution doesn't force users to avoid using exports while they are silently supported. The first internal solution was keeping dpkg_build_export function but also passing custom shell exports (from dpkg_runbuild_prepend) to sbuild environment. And a warning about migration was shown. Later I removed this to make new patchset less invasive for downstreams. Anyway, if we agree that "dpkg_build_export" (like API function) is more preferable, I can get back this solution with warnings.