From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6499063932287713280 X-Received: by 10.28.8.12 with SMTP id 12mr346549wmi.1.1513268446635; Thu, 14 Dec 2017 08:20:46 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.223.154.44 with SMTP id z41ls1316484wrb.6.gmail; Thu, 14 Dec 2017 08:20:46 -0800 (PST) X-Google-Smtp-Source: ACJfBovhWs09epzLI2Iq04C3ibw6PVuZlJ3XLjOyfNy47f87VBSEr6kXmRVOinU2kf8r4WEf6iRc X-Received: by 10.223.154.111 with SMTP id z102mr806357wrb.14.1513268446204; Thu, 14 Dec 2017 08:20:46 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513268446; cv=none; d=google.com; s=arc-20160816; b=YeEq/FC9GQ4eiC2+S7/7L633dKfSZTTDAH2BCqacOcxIEMIfQqVpRcZp45uVDsJBwT GDg/4HdOSsCMjxNhXzosBHTZqnzRrRxO7P4YO6o338rEfavQmXLN3T6rumvxJCC5a0q7 T5qUdsQiCOQfBVeDMX/L3hosHvsjobJbR5qi9bHAHwCcjNrv8EuGl1IDdshDwxaCwNNA HYU+5qTfLo0H10gSbGMGPWWY3uLXO4F//+EkiOJ1AA78R/zrP8Pl3hOWD4PL/ns3WiMc W3TJk3SFLNYLKYLdBgJdE27V7A8DpVMaCYFCwtdgKbFjXDE3JMPSQ8NqEyHQwVL/P8xO i5Vw== 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=he++AhU485Je2JzT4LectflhJ00QQ8lnb5sLGQLC8ZI=; b=wwqOxEQViQ7Dr93nJV9S2NYvfiquv9u5j/IZoaxiBbbqONtO9x4nTX5LBpr/3grO5L 2ApfsV9PM8EIF7sKgk2AajmovVD1a7UEe2sNXpdomRT5atFKYP7qLTF46Pztohrvsb8+ caaUVRUE0s9pMwzpTEgJScD8X7PsL/yAKZJps3RdoqA2YZawysy1D9vLsGiMdw4/FQ5U IS/i5U/uEHfnvGEbfml1lgaJOb7wAxB1zOg0bXB+1hM8MC5hWajeRYYX4ofvnvU5TCeO veRXkp/uBPRrh6nK/BPP63Hx0LK1u3QmKBqASUKG6QeEQ9k01+Yun5yFpx2N5hrdsR+p WFsg== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Return-Path: Received: from david.siemens.de (david.siemens.de. [192.35.17.14]) by gmr-mx.google.com with ESMTPS id a22si548932wmg.0.2017.12.14.08.20.46 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 08:20:46 -0800 (PST) Received-SPF: pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) client-ip=192.35.17.14; Authentication-Results: gmr-mx.google.com; spf=pass (google.com: domain of henning.schild@siemens.com designates 192.35.17.14 as permitted sender) smtp.mailfrom=henning.schild@siemens.com Received: from mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by david.siemens.de (8.15.2/8.15.2) with ESMTPS id vBEGKjZt008696 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Dec 2017 17:20:45 +0100 Received: from mmd1pvb1c.ad001.siemens.net (md1pvb1c.ad001.siemens.net [139.25.68.40] (may be forged)) by mail3.siemens.de (8.15.2/8.15.2) with ESMTP id vBEGKjSs025647; Thu, 14 Dec 2017 17:20:45 +0100 Date: Thu, 14 Dec 2017 17:20:44 +0100 From: Henning Schild To: Claudius Heine Cc: "[ext] claudius.heine.ext@siemens.com" , Subject: Re: [RFC PATCH 0/1] Special debian depends entries Message-ID: <20171214172044.2eaf4180@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <1513263138.31110.37.camel@denx.de> References: <20171213160710.3610-1-claudius.heine.ext@siemens.com> <20171214144205.063a6c49@mmd1pvb1c.ad001.siemens.net> <1513260757.31110.23.camel@denx.de> <20171214153628.1b3d6d36@mmd1pvb1c.ad001.siemens.net> <1513263138.31110.37.camel@denx.de> X-Mailer: Claws Mail 3.15.0-dirty (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: u2KkdW0mkbzx Am Thu, 14 Dec 2017 15:52:18 +0100 schrieb Claudius Heine : > On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote: > > Am Thu, 14 Dec 2017 15:12:37 +0100 > > schrieb Claudius Heine : > > > > > Hi Henning, > > > > > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild wrote: > > > > Am Wed, 13 Dec 2017 17:07:09 +0100 > > > > schrieb "[ext] claudius.heine.ext@siemens.com" > > > > : > > > > > > > > > From: Claudius Heine > > > > > > > > > > Hi, > > > > > > > > > > this patch is to start the discussion about how to implement > > > > > the > > > > > debian depends. > > > > > > > > > > Instead of going the just 'echo ${DEBIAN_DEPENDS}' route, I > > > > > chose > > > > > to > > > > > be backwards compatible. Another reason for this is also for > > > > > the > > > > > possible next feature where ISAR 'DEPENDS' or 'RDEPENDS' will > > > > > be > > > > > converted to the package specific 'DEBIAN_DEPENDS'. > > > > > > > > With the current nature of dpkg-raw DEPENDS and RDEPENDS make no > > > > sense. > > > > Maybe some day the class will do more than just wrap stuff in a > > > > package, but at the moment i do not see that coming. > > > > And even if that ever happened the class could take care of > > > > turning > > > > the > > > > bitbake-list (R)DEPENDS into a Debian comma-seperated list. > > > > > > > > I tried your code in a bash (not in Isar/bitbake etc.) and i got > > > > a > > > > few > > > > more commas that i would have expected. > > > > > > > > 'libc, (>=, 2.16)', 'tar, |, bsdtar', systemd > > > > > > > > Shell code is nasty, i think i do not even want to know why it > > > > worked for you or wether it would work in Isar with my build > > > > env. > > > > > > I works in here because the ${DEBIAN_DEPENDS} is inserted by > > > bitbake > > > before any shell is executed. So in shell code for this example > > > looks > > > like this: > > > > > > DEBIAN_DEPS="$(for i in 'libc (>= 2.16)' 'tar | bsdtar' > > > systemd;do > > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')" > > > > > > If you try that out with your shell: > > > > > > $ echo "$(for i in 'libc (>= 2.16)' 'tar | bsdtar' systemd;do > > > echo > > > $i,;done|tr '\n' ' '|sed 's/, *$//')" > > > libc (>= 2.16), tar | bsdtar, systemd > > > > > > It works correctly just like in bitbake. > > > > > > DEBIAN_DEPENDS is not a shell variable but a bitbake one. > > > > > > But I get your point that this is confusing and error-prone. Doing > > > it > > > with python might be easier. > > > > It is just one of multiple points. > > > > Could you live with the simple solution of just taking the string > > from > > the recipe and requiring recipe-updates? > > I would rather not break backward compatibility. > > I know that isar is not at a stage were a fancy idea like this one > really matters, but for me this issue is currently not important > enough to justify this breakage and the work to change all the > recipes relying on the old behavior. How many recipes are we talking about here 3-5 in your layer? Let us please not make this about principle but just be pragmatic about it. The change to the recipes is trivial! I will come over to your desk and help you with it, but only if you are doing the 15+ on my side ;). Christian said he wants to be able to express versions and choices and does not care about compatibility. And so far i did not hear any other complaints. To me it is the perfect time to take the issue seriously. Because now we can still change the interface without making too many people angry. > So for me we either fix it in a compatible way, like my patch does, or > don't bother and wait for a usecase where we cannot advice the user to > just debianize the sources in some way. No, Christian identified a bug that should be fixed. You can always debianize sources, you could probably do everything that dpkg-raw is doing in a /debian instead of a /DEBIAN folder. But this has nothing to do with whether, when, or how the bug at hand should be fixed. Henning > Cheers, > Claudius >