From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6499063932287713280 X-Received: by 10.25.23.84 with SMTP id n81mr577301lfi.0.1513326267608; Fri, 15 Dec 2017 00:24:27 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 10.46.33.148 with SMTP id h20ls1017188lji.3.gmail; Fri, 15 Dec 2017 00:24:26 -0800 (PST) X-Google-Smtp-Source: ACJfBouP8rTulTVADeo40ZGDN/RPcMwR0aFEjLEuBuFDo1NcUvEdfBuUyf3oBeKdE4H1h/5y81B/ X-Received: by 10.46.46.10 with SMTP id u10mr642059lju.10.1513326266791; Fri, 15 Dec 2017 00:24:26 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1513326266; cv=none; d=google.com; s=arc-20160816; b=JCfIZu8YcuYIZgMncThrkNv+Up6oY4X3clB1mANccmv8BDg1f/+rwSEfMqabIu57n6 CI6Fgf3MaGVB1k4t5RxFbaMxymKnm++QYoQ9/MHZou+GEdwtpdkWhaU1Tg3yp39dJpwg P53+SKq1p0QtDBYHUpHmAdV6siXHRuH8oUUFkkZ5/0Md1gZH2LJvJEC7BP9t0fXUwReE ysAe1Cv1w4yc2gwrAk+4Ig84dunOMpwAvC6RE/CmWS12rcrUQERmGMoEvMfzxJf+y1HE pYHSlWySs8hau1w3HLBV8FXzQn6UUrajrKCq/14dJQNBc9awy8kXnB8+ZuDQ+84iGzRC J1gA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=mime-version:references:in-reply-to:date:cc:to:from:subject :message-id:arc-authentication-results; bh=Ysh0a5BceknwNhp1m1g4myNaE7obRuHdM6qc/PcYqvk=; b=adGtqEV+lvjoF3kjVObs1ZpifTb/DIK4eP6aHR73KKeRXpgisrr5R1luFJR5uULydu tIObCzC9h72MTZbM47XPK6iy2k/tU4Tgd6/gfsrALK6szLBWRZnDiWoERJiQnSTJWeHD abxYeLztHTAPGjMPKFxa16da+CzvGUqjYueHUpzjeg6rc0r39Oh++vFS2oJvYM3H21GQ rkhvYdtEcoSyVLpA58g3eVAGgMvVZXL713X2ZGZFI3fqc3cajVHIyfweNihsUjlkW5mM IWJZUhyL+d8w2e6IHV0YaRSzrSncel2BmV4LeNBnzKuDsuooY/ajgdC2SpAiz03BR7P3 PpVQ== ARC-Authentication-Results: i=1; gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Return-Path: Received: from mail-out.m-online.net (mail-out.m-online.net. [212.18.0.10]) by gmr-mx.google.com with ESMTPS id y16si536654lje.2.2017.12.15.00.24.26 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 15 Dec 2017 00:24:26 -0800 (PST) Received-SPF: neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) client-ip=212.18.0.10; Authentication-Results: gmr-mx.google.com; spf=neutral (google.com: 212.18.0.10 is neither permitted nor denied by best guess record for domain of ch@denx.de) smtp.mailfrom=ch@denx.de Received: from frontend01.mail.m-online.net (unknown [192.168.8.182]) by mail-out.m-online.net (Postfix) with ESMTP id 3yyk4B0nbzz1qvnH; Fri, 15 Dec 2017 09:24:26 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 3yyk4B0V2Sz1qqtv; Fri, 15 Dec 2017 09:24:26 +0100 (CET) X-Virus-Scanned: amavisd-new at mnet-online.de Received: from mail.mnet-online.de ([192.168.8.182]) by localhost (dynscan1.mail.m-online.net [192.168.6.70]) (amavisd-new, port 10024) with ESMTP id wyg4YwtmZg39; Fri, 15 Dec 2017 09:24:24 +0100 (CET) X-Auth-Info: PcHLXVcVUnLdjJG2SLTGUQfOHOXKtCbePcAvmM2ko+c= Received: from orrorin (p578adb1c.dip0.t-ipconnect.de [87.138.219.28]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.mnet-online.de (Postfix) with ESMTPSA; Fri, 15 Dec 2017 09:24:24 +0100 (CET) Message-ID: <1513326257.31110.77.camel@denx.de> Subject: Re: [RFC PATCH 0/1] Special debian depends entries From: Claudius Heine To: Henning Schild Cc: isar-users@googlegroups.com, "[ext] claudius.heine.ext@siemens.com" Date: Fri, 15 Dec 2017 09:24:17 +0100 In-Reply-To: <20171214183122.5acc4942@mmd1pvb1c.ad001.siemens.net> 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> <20171214183122.5acc4942@mmd1pvb1c.ad001.siemens.net> Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="=-e2xgj7dTWr0d+Ocae/VF" X-Mailer: Evolution 3.26.2 Mime-Version: 1.0 X-TUID: a8IQB9hvEz1P --=-e2xgj7dTWr0d+Ocae/VF Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, 2017-12-14 at 18:31 +0100, Henning Schild wrote: > Am Thu, 14 Dec 2017 18:02:00 +0100 > schrieb Claudius Heine : >=20 > > On Thu, 2017-12-14 at 17:20 +0100, Henning Schild wrote: > > > Am Thu, 14 Dec 2017 15:52:18 +0100 > > > schrieb Claudius Heine : > > > =20 > > > > On Thu, 2017-12-14 at 15:36 +0100, Henning Schild wrote: =20 > > > > > Am Thu, 14 Dec 2017 15:12:37 +0100 > > > > > schrieb Claudius Heine : > > > > > =20 > > > > > > Hi Henning, > > > > > >=20 > > > > > > On Thu, 2017-12-14 at 14:42 +0100, Henning Schild > > > > > > wrote: =20 > > > > > > > Am Wed, 13 Dec 2017 17:07:09 +0100 > > > > > > > schrieb "[ext] claudius.heine.ext@siemens.com" > > > > > > > : > > > > > > > =20 > > > > > > > > From: Claudius Heine > > > > > > > >=20 > > > > > > > > Hi, > > > > > > > >=20 > > > > > > > > this patch is to start the discussion about how to > > > > > > > > implement > > > > > > > > the > > > > > > > > debian depends. > > > > > > > >=20 > > > > > > > > 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'. =20 > > > > > > >=20 > > > > > > > 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. > > > > > > >=20 > > > > > > > I tried your code in a bash (not in Isar/bitbake etc.) > > > > > > > and i > > > > > > > got > > > > > > > a > > > > > > > few > > > > > > > more commas that i would have expected. > > > > > > >=20 > > > > > > > 'libc, (>=3D, 2.16)', 'tar, |, bsdtar', systemd > > > > > > >=20 > > > > > > > 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. =20 > > > > > >=20 > > > > > > 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: > > > > > >=20 > > > > > > DEBIAN_DEPS=3D"$(for i in 'libc (>=3D 2.16)' 'tar | bsdtar' > > > > > > systemd;do > > > > > > echo $i,;done|tr '\n' ' '|sed 's/, *$//')" > > > > > >=20 > > > > > > If you try that out with your shell: > > > > > >=20 > > > > > > $ echo "$(for i in 'libc (>=3D 2.16)' 'tar | bsdtar' > > > > > > systemd;do > > > > > > echo > > > > > > $i,;done|tr '\n' ' '|sed 's/, *$//')" > > > > > > libc (>=3D 2.16), tar | bsdtar, systemd > > > > > >=20 > > > > > > It works correctly just like in bitbake. > > > > > >=20 > > > > > > DEBIAN_DEPENDS is not a shell variable but a bitbake one. > > > > > >=20 > > > > > > But I get your point that this is confusing and error- > > > > > > prone. > > > > > > Doing > > > > > > it > > > > > > with python might be easier. =20 > > > > >=20 > > > > > It is just one of multiple points. > > > > >=20 > > > > > Could you live with the simple solution of just taking the > > > > > string from > > > > > the recipe and requiring recipe-updates? =20 > > > >=20 > > > > I would rather not break backward compatibility. > > > >=20 > > > > 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. =20 > > >=20 > > > 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 > > > ;). > > >=20 > > > 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. > > >=20 > > > 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. > > > =20 > > > > 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. =20 > > >=20 > > > No, Christian identified a bug that should be fixed. > > >=20 > > > 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. =20 > >=20 > > 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? >=20 > 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. >=20 > > For me its about pragmatism not about principles. Just fix the code > > at > > one place and not in many. :) >=20 > 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". I know you don't mean that, but that still sounds like saying "Because we could do something wrong, do nothing instead." Not really an argument I would follow. The idea of "The only bug free code is no code." was to me always an argument for minimalism, reviews, upgradeability and so on, not for replacing code with something that does almost nothing and then having to work around that somewhere else. I send a python based solution to the list, so we could base further discussion on this one. But I suspect our views are pretty much set here. So maybe we need some third party to decide. Cheers, Claudius --=20 DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: (+49)-8142-66989-54 Fax: (+49)-8142-66989-80 Email: ch@denx.de PGP key: 6FF2 E59F 00C6 BC28 31D8 64C1 1173 CB19 9808 B153 Keyserver: hkp://pool.sks-keyservers.net --=-e2xgj7dTWr0d+Ocae/VF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part Content-Transfer-Encoding: 7bit -----BEGIN PGP SIGNATURE----- iQIzBAABCgAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAlozhrEACgkQEXPLGZgI sVMoJhAAxtIaLB1hEx7rox397EAXo3Tz4e3gxlrjotOpMY6l1oQnhhAuvuJXmn4Q rhLz/UAOYOW2qvczPH88zECLL+QwLUePYKjavjULmvgmu3czZ6xPWvMLO+KIRgHT iL2IP0xaAwJVqqH8G6AKIKmIgi72RLXJGOs7Qyf3XCfi/eLVzf8tof5W/9j/AmPW ahGF4UO2QpBzTVQdfaO3cKPAMCZaXTZO8FvfXDU2Z6T/M5nKwwgOuJNyIpWeqScC fhI3AinmoRdVkOtefZzy79+SrbmgA73uXCZhkGKlOVuILVDVD8q7IbW7IM7TsO45 EIXLvCJNPNCqyjIBt7Ueml7jh1sLIKFH7SG75MJWVpo5likhX/U+mxAEfLuSs6WU +wyoKAhEyOfSBkSLcjf3vkR2ImX6ImGUEogr3qZMF6265ebW3zKdcymY6l61YxHm uqT1yYLjhVt8/nyKLJFGg1EJbl/l6iRDL/f16N5tNrYDTC5GxA5iTPrnyBSy6J7k tjqXhtzPYKF+/vFix8WKUCL8RsILXDNglHKwnlqNUxT6eR+z9mpy0Bif5ju/zaGH d6TX0TExKeVAHmxA1bYIZvxcMI0/JhLY7vFLoY7KmjmarnqhqGLwvB1A15wXy5RO mmWLY6uj921Gh2Bsw4tMEKXlZHxVs76cH43+bGBmR6CAoWHcReg= =QbnG -----END PGP SIGNATURE----- --=-e2xgj7dTWr0d+Ocae/VF--