From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6499063932287713280 X-Received: by 10.80.195.1 with SMTP id a1mr3294019edb.8.1513272685245; Thu, 14 Dec 2017 09:31:25 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.80.212.18 with SMTP id t18ls2509779edh.6.gmail; Thu, 14 Dec 2017 09:31:24 -0800 (PST) X-Google-Smtp-Source: ACJfBov5s6U+pJyO1Nk4yNKELWrO1VUInqjlPalvWD+2TldGZ4CAY6dwi4Da6c4xHqgmfW00mLKA X-Received: by 10.80.137.157 with SMTP id g29mr3269760edg.2.1513272684795; Thu, 14 Dec 2017 09:31:24 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513272684; cv=none; d=google.com; s=arc-20160816; b=MQP7Ww/xS1X/KJB16NW/oe6I/JEphSPYg5DUWo17u8NIZW4jyuCuli1jVuloIxC5Au SN9Sazo5QOed8UIE2m2gWkj5HWPhUa/KW+u6BiSPFoRXe1JXJHKpi3ZqJCSjzXJUgPTX kfRYlbVEgrHlQIfR1OnSA706OTJ0w4UpdT286e5TqVFHFXBu7gVg24kD0Y1g6Hy8GgeX FbNhvJz1j9dbnZlirxq9ievgXeVwkvxTsJpXpUyqDmTYqYV7tj40aksZssHYiiBGrCmn mB1299Hgjk+TuN0HGcBjtX2GWRh5uU7eE9jLWsvlfERV564qQLI05VH6UrcDyMVr3+z8 GLlA== 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=eRHEdYNmusJBYIYHkUFdxnLsyFlwASxqjVJ8mLrb/+8=; b=AVlnZyQ2PhxvIpU4SNKga9jIl3ng0JmCFTk70G+/fWX2m0VtqrTnolqy6pzCSUbGWd R909SnGTx070iNvlsXybDALWMrABTMj9XplJ8zAI3R+7hxakk0OtEwvA7a4Z+v9w0gsZ MwoQcVmLRIkS4fFqnk7hX6nAaeci2gcCKdfcvS17hcTdVwUmgOLRzGbsVoyUEWbzJ3qH cuo6zX9IGzSgsDCHFL8FB6f6ACezGKwO3iW/saeM48/vgTJLE+0A5RPjE28OSc2W8msL zQBRmE8vEI9WJaXiLUWKh3DINj3ugmBcB8+Lac8m7is2ZjpqelMENup1Rr/S+gq9iRRC iTcg== 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 s29si551030eds.0.2017.12.14.09.31.24 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Dec 2017 09:31:24 -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 mail3.siemens.de (mail3.siemens.de [139.25.208.14]) by goliath.siemens.de (8.15.2/8.15.2) with ESMTPS id vBEHVNiC027560 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 14 Dec 2017 18:31:23 +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 vBEHVNC5019522; Thu, 14 Dec 2017 18:31:23 +0100 Date: Thu, 14 Dec 2017 18:31:22 +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: <20171214183122.5acc4942@mmd1pvb1c.ad001.siemens.net> In-Reply-To: <1513270920.31110.62.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> <20171214172044.2eaf4180@mmd1pvb1c.ad001.siemens.net> <1513270920.31110.62.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: Af/Lj1OAJ+60 Am Thu, 14 Dec 2017 18:02:00 +0100 schrieb Claudius Heine : > On Thu, 2017-12-14 at 17:20 +0100, Henning Schild wrote: > > 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. > > You haven't given any advantages to having a comma seperated list in > the DEBIAN_DEPENDS yet. Ok, you don't like the shell code, fine. But > if I invest the about same time that it takes to fixing all my 5 > recipes into writing the same transformation I did in python and have > a compatible fix for this issue, isn't that better than having an > incompatible fix? The benefit is obvious, reduced complexity and everything that comes with it. Code is error prone, so replacing code with "no code" is clearly a good idea. The only reason we are having this discussion is because of just one line of code that looked harmless at the time of writing. > For me its about pragmatism not about principles. Just fix the code at > one place and not in many. :) No, delete the broken code and hope you get it right this time. And "no code" is very likely to have less bugs than any positive number of "code". Henning > Cheers, > Claudius >