From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7057122428766388224 X-Received: by 2002:a7b:cb9a:: with SMTP id m26mr5310749wmi.18.1643793212021; Wed, 02 Feb 2022 01:13:32 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:adf:f792:: with SMTP id q18ls32956wrp.1.gmail; Wed, 02 Feb 2022 01:13:31 -0800 (PST) X-Google-Smtp-Source: ABdhPJwCDjx+05Jy7p1xWWO9JhCbutmgMyvP6OLZqLJQpMmSp7cZu4V/e57pSY33PGnMAvwuBCTj X-Received: by 2002:a05:6000:1548:: with SMTP id 8mr23675950wry.504.1643793211061; Wed, 02 Feb 2022 01:13:31 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1643793211; cv=none; d=google.com; s=arc-20160816; b=a7XTFEnvqRegESHjd7KTL3o48iFVlezH/xmqQSrQFSiMZPMQxsXIlZAS35T/bCWSbd D/0aI0zTTExAA7kXdZ3IG+JMvOnU1sm0lQ5kM+akr0Cf9IObZPg3GG7H2M7fMHIndwJ4 xulwSbKGJlVBhGIzdfhr+HVyxm0mlBORNh+vxu5xCMgngo3CStmb6uxjBXUgfq2+8oFJ dtyXIS6oPvPWwV2/B+X9iKuO/vwIQY13tWFzwUZcfhXiU2YpIPvbwQ21wtIifL7i71Z6 vL9GSMH8ynjC9Qu2dwYjYBqz0yxSR8gjPw8ABeQ1ZkfXNXhPa5N232f2DNXh4RRattRE 2tJQ== 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:to:from; bh=Z6zD+hWc4KOkVXYp3lehOVSiA82aiIN1aIUMM3R4Aiw=; b=g+Q6wnpjD5yn/S/pTCaepsbTncqs4bq+Z0aQpJKvAN4J1A3VuQyrDP/LLH4oXNdMhL bTTLTtwZCDDkYQqT7kbJ9wb2wlc8y3nbqf6JBl9ayDyhJlAG1vSbg3ZV82ETdFSQ7/3E O+4GNMFdsRfEoHxe+nmwkB9YobZE6j9aUhA7S54nwwlfyjnEYWTlAaqnIg0Y5KWnKQmd yDSVQtpbbyoTG0GweQhUtevSKb9AmOCZWl43XEqefPupo8cxPNtCcC9kmtk122rg+qEc s200qvhcaIsupZrZm3lJYbs8YRFxTser9H8U6bewuBhrA5CfAlwTcK/fjz0bEqA6iGPP HHBw== 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 h16si306309wml.0.2022.02.02.01.13.30 for (version=TLS1_2 cipher=ECDHE-ECDSA-CHACHA20-POLY1305 bits=256/256); Wed, 02 Feb 2022 01:13:31 -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 2129DKup023414 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 2 Feb 2022 10:13:21 +0100 From: Uladzimir Bely To: "Moessbauer, Felix (T CED SES-DE)" , "isar-users@googlegroups.com" , Jan Kiszka Subject: Re: [PATCH v5 07/12] sbuild: support of shell exports from dpkg_runbuild_prepend Date: Wed, 02 Feb 2022 12:13:20 +0300 Message-ID: <4880928.Qq0lBPeGtt@home> In-Reply-To: References: <20220201170038.5723-1-ubely@ilbers.de> 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: 87B2whuN8s+6 In the email from Wednesday, 2 February 2022 11:52:29 +03 user Jan Kiszka wrote: > On 02.02.22 09:46, Moessbauer, Felix (T CED SES-DE) wrote: > >> -----Original Message----- > >> From: isar-users@googlegroups.com On > >> Behalf Of Jan Kiszka > >> Sent: Wednesday, February 2, 2022 7:57 AM > >> To: Uladzimir Bely ; isar-users@googlegroups.com > >> Subject: Re: [PATCH v5 07/12] sbuild: support of shell exports from > >> dpkg_runbuild_prepend > >> > >> On 01.02.22 19:41, Uladzimir Bely wrote: > >>> 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. > >> > >> This is not necessarily what I'm suggesting. Your conversion series works > >> without that API, primarily using template. We also have build profiles. > >> But we first of all need to define what we actually want. > >> > >> The benefit of pushing things into the build env, rather than feeding it > >> from the recipe, is likely that the resulting deb-src of such generated > >> packages can actually be used for rebuilding independently of Isar. So > >> there is likely value in deprecating classic export. > > > > Using environment variables to control the build in Debian/rules is > > generally discouraged (except for DEB_BUILD_PROFILES and > > DEB_BUILD_OPTIONS). But even for these variables, semantics are > > documented [1] and we / an ISAR user should strictly follow them when > > packaging. > > > > There are also reasons why you want to build a package in a clean > > environment (e.g. to avoid accidentally setting CC or CXX to icc or > > clang). Hence, I highly vote for not forwarding the environment into the > > sbuild build environment. > ...without a warning about a grace period during that we will still do > that to allow downstream migration. Then we have a plan, I would say. > > Jan To make things clear, there are now three options: 1) (Current) Just support passing shell exports user done in dpkg_runbuild_prepend to (s)build environment. Users of downstreams are not notified, so they continue using these exports. 2) Continue support custom shell exports by passing them to (s)build env, BUT show warnings, that user should use some 'dpkg_build_export'. In general, this doesn't differ much from the previous approach. 3) Continue support custom shell exports by passing them to (s)build env, BUT show warnings, that this stuff should be converted to templates. After some period, stop supporting exports. 4) Doesn't support shell exports passing to (s)build env, so it will immediately break the builds. As I understand correctly, the way (3) is the best solution. -- Uladzimir Bely