From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 6654880414262362112 X-Received: by 2002:a1c:9cc3:: with SMTP id f186mr411508wme.11.1549476535730; Wed, 06 Feb 2019 10:08:55 -0800 (PST) X-BeenThere: isar-users@googlegroups.com Received: by 2002:a1c:840e:: with SMTP id g14ls473417wmd.5.canary-gmail; Wed, 06 Feb 2019 10:08:55 -0800 (PST) X-Google-Smtp-Source: AHgI3IYXShJTnFlQ9LRMTLrUc2VCub1Pvtz4IAd4Km03yP5H1TRF/2QZ+waNLLyRnakoqxlWP/Kd X-Received: by 2002:a1c:e357:: with SMTP id a84mr405043wmh.13.1549476535199; Wed, 06 Feb 2019 10:08:55 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1549476535; cv=none; d=google.com; s=arc-20160816; b=VHeu5WDdIgRu1Wejjpe5Ym+olHmJMqMMZxf12LvwG1m1lqBAoxJTvKtA+Miu3H9fmf hJOvxjdNJAI4Git1JIqvlukHJXaKwILMsmuVhMsHZLDApjgGTCIfKdJ/IokUDRi1CNkr H6BaWy6ars2IF2CqgcFYMHKi6zVb0G9kwktkRjSG0Go2uwpbzOv2bgRBgN2w4F7MYLkY jupjMGR0glJx3RpcR2QmWOv+E6xQ0klVytGu/acYcggBGsoffE+lxBfxOdouwPXDbDT/ Hm5b4+baH2c2CKMVyeOmd/dxNNVUbG6pcm2ygYZ3sBrF1+VlE8OgxSEYZhdA3W4AAubs 96+Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=date:user-agent:message-id:from:to:subject:references:in-reply-to :content-disposition:mime-version; bh=2VRwZrqdFnALwwGvGl5IAeOXVEQcHpsVBUrq3UWammk=; b=SuwOzW76dlVHT2+CYR7DY2GCjk+EcP6Masmy3T4tu8ntKRzeCzbWmbJ4yLI6yKY32d QyD2BeazpqIWHxufkDliF/TWZhTbFlN0FmGpgqXFHOHYbP2nS8bR50CHTM+jWmKvxJhu hdCM3aXa/kbuKWuBqNn/TheBxFHqaeMjfAsqiMbld6WIzXjxEeJu0U2wa3xeTH96dWY1 WcOyJHdWoPSt7Vlmc9s5I4tCeJS2MR2I4yqtRsmD81K+Q0U3XkD7KIsoSeUrNGqWmecZ g6WStXJjeIw8F1ydka2XSqx2RnTc4N1gfcxG78bmFms14qXfcBYnpBdXIF6hWXh9AlQ9 MEdw== 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 g2si572286wrp.1.2019.02.06.10.08.55 for (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 06 Feb 2019 10:08:55 -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 43vqFf6df5z1r8Wt; Wed, 6 Feb 2019 19:08:54 +0100 (CET) Received: from localhost (dynscan1.mnet-online.de [192.168.6.70]) by mail.m-online.net (Postfix) with ESMTP id 43vqFf6Jg0z1r2H5; Wed, 6 Feb 2019 19:08:54 +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 UEcCPKGSc90g; Wed, 6 Feb 2019 19:08:53 +0100 (CET) X-Auth-Info: NDnyybRM0VgC9C/VkJmLMUFasdxPJ4jnKMbq5Qdlod0= Received: from localhost (ipservice-092-218-254-113.092.218.pools.vodafone-ip.de [92.218.254.113]) (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; Wed, 6 Feb 2019 19:08:53 +0100 (CET) Content-Type: multipart/signed; micalg="pgp-sha256"; protocol="application/pgp-signature"; boundary="===============5568494826384715101==" MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <1549469493.6521.19.camel@siemens.com> References: <1549459957.6521.14.camel@siemens.com> <7ed827ce-2243-4341-ee61-6d3e3881bb4a@siemens.com> <1549469493.6521.19.camel@siemens.com> Subject: Re: [RFC] Documentation: dependencies specification in Bitbake and Debian To: "Cirujano Cuesta, Silvano" , "Heine, Claudius" , "isar-users@googlegroups.com" From: Claudius Heine Message-ID: <154947653156.16220.124019049728000112@ardipi> User-Agent: alot/0.8 Date: Wed, 06 Feb 2019 19:08:51 +0100 X-TUID: YyW1AvT28fro --===============5568494826384715101== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi Silvano, Quoting Cirujano Cuesta, Silvano (2019-02-06 17:11:40) > Hi Claudius, >=20 > First of all thank you very much for your quick and valuable feedback! >=20 > On Wed, 2019-02-06 at 16:00 +0100, Claudius Heine wrote: > > > ## Dependencies table > > >=20 > > > Acronyms: > > > > Bt =3D Buildtime > > > >=20 > > > > Rt =3D Runtime > > > > Variable=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0| Bt Bitbake | Bt Debian | Rt Functional | Rt Package | > > > > ------------------ |:----------:|:---------:|:-------------:|:-----= -----:| > > > > `DEPENDS`=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0| > > > > `IMAGE_INSTALL`=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0x=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| > | `IMAGE_PREINSTALL`=C2=A0 > > >=20 > > > =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0x=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0| > > > > `DEBIAN_DEPENDS`=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0|=C2=A0=C2=A0=C2=A0= =C2=A0=C2=A0x=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0| > >=20 > > While this graphic looks very simple, that is misguiding. > > IMO they could lead to a viewpoint that makes really understanding what= =C2=A0 > > is happening more difficult. Bitbake works its dependency magic on task= =C2=A0 > > level and provides DEPENDS to express common task dependencies across= =C2=A0 > > recipes as syntax sugar. > >=20 > > IMAGE_INSTALL + IMAGE_PREINSTALL + DEBIAN_DEPENDS etc. is more about=C2= =A0 > > expressing debian package installation and a bit more. This time it is= =C2=A0 > > isar syntax sugar that puts the entries from IMAGE_INSTALL into DEPENDS. > >=20 > > IMO this sugar, while it makes some things more easy (with big=C2=A0 > > assumptions), makes some things more difficult (recipes provide multipl= e=C2=A0 > > packages). AFAIK this wasn't changed because historic reasons. >=20 > I'm not sure I get your point here... >=20 > My interpretation of your comment is that the table is right, but you wou= ld prefer the table not to show the syntactic sugar. > Mostly to avoid people getting into anti-patterns, I assume. > Did I get it right? >=20 > The separation between Bitbake dependency at task level and Debian depend= ency at package level is clear to me, perhaps it's only the presentation of= the table that is misleading... In general you would need 3 such tables. Two for package recipes (one for dpkg and one for dpkg-raw) and one for image recipes. My main issue is that you are comparing things here from different classes and bitbake in general. While the table is correct it is misleading IMO. [...] > >=20 > > > Opposed to `IMAGE_INSTALL`, this doesn't affect any runtime dependenc= ies. > > >=20 > > > This variable can be seen as the counterpart at buildtime for [`IMAGE= _PREINSTALL`](#functional-runtime-image_preinstall) (runtime) and [`DEBIAN_= DEPENDS`](#package-runtime-debian_depends) > > > (runtime). > > >=20 > > > ### Bitbake buildtime: `IMAGE_INSTALL` > > >=20 > > > `IMAGE_INSTALL` specifies recipes available in one of the layers that= have to be built. > And at the same time specifies that the Debian package= s resulting=C2=A0 > >=20 > > from the recipes have to be installed in the image (see=C2=A0 > > [below](#functional-runtime-image_install) for more information). > > >=20 > > > The logical place to use this variable is an **image** recipe or **co= nfiguration** file (distro, layer, ...). > >=20 > > The only places where this is possible. >=20 > Does "is possible" really mean that either you get an error or it's being= silently ignored? > Or there is no enforcement, but it shouldn't be done elsewhere? It is silently ignored if it not part of an image recipe or the global configuration. Each recipe runs with its own copy of the bitbake data store, so you cannot effect what goes into an image via IMAGE_INSTALL from a package recipe for instance. [...] > > > ### `RRECOMMENDS` > > >=20 > > > This variable provides ["a list of packages that extends the usabilit= y of a package"][bb-rrecommends]. > > >=20 > > > In ISAR there is only one way to achieve the same: > > >=20 > > > 1. Adding them to the [`Recommends` of the package `debian/control`][= pkg-rels] file. > >=20 > > You can do this, but recommended or suggested packages are not installe= d=C2=A0 > > per default, but you could change that by overwriting the isar-apt.conf= =C2=A0 > > of the isar-bootstrap-*.bb recipes. >=20 > That's clear to me in the case of Debian. > I've also assumed that the same applies to Yocto/OE Well I haven't tried that, but I suppose that you can enable recommended packages just via a configuration setting. Not so here. > > > ### `PACKAGES` > > >=20 > > > This variable provides ["the list of packages the recipe creates"][bb= -packages]. > > >=20 > > > In ISAR there is only one way to achieve the same: > > >=20 > > > 1. Specifying multiple packages in the [`debian/control` file][pkg-co= ntrol] being provided by a recipe. > >=20 > > Doing so might get problematic because you then cannot use IMAGE_INSTAL= L=C2=A0 > > to install those specific packages, because they then will be added to= =C2=A0 > > DEPENDS (as I said IMO bad idea) and have to remove those from DEPENDS= =C2=A0 > > (DEPENDS_remove) and add the correct recipe name manually. >=20 > Well, `DEPENDS` would be needed to get the "Buildtime dependency" (to ens= ure that the recipe gets executed and the Debian packages get built) and th= e control file would take care of the "Runtime > dependency" (to get the functionality in the image or a dependency of a p= ackage resolved). >=20 > I'm not sure what you mean it's a bad idea. > Hopefully you don't mean that having `DEPENDS` in a package recipe is a b= ad idea, since that's what the example does [2]. No. I called inserting IMAGE_INSTALL into the DEPENDS of an image was a bad idea when that was done, because that assumes that a recipe provides just one package with the same name. If you want for instance a "curl" recipe to generate a "libcurl" package and you want to install just that, you would have to add 'curl' into DEPENDS and 'libcurl' into IMAGE_INSTALL. But because IMAGE_INSTALL now adds 'libcurl' into DEPENDS and there is no 'libcurl' recipe, you would have to remove 'libcurl' from DEPENDS manually. regards, Claudius >=20 > [2] https://github.com/ilbers/isar/blob/6c5db020b9b837d7b0ce63bfc719f9192= e725f26/meta-isar/recipes-app/example-hello/example-hello.bb#L15 >=20 > Regards, > Silvano >=20 > --=20 > You received this message because you are subscribed to the Google Groups= "isar-users" group. > To unsubscribe from this group and stop receiving emails from it, send an= email to isar-users+unsubscribe@googlegroups.com. > To post to this group, send email to isar-users@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgi= d/isar-users/1549469493.6521.19.camel%40siemens.com. > For more options, visit https://groups.google.com/d/optout. -- 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 --===============5568494826384715101== MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Description: signature Content-Type: application/pgp-signature; name="signature.asc"; charset="us-ascii" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEb/LlnwDGvCgx2GTBEXPLGZgIsVMFAlxbIq8ACgkQEXPLGZgI sVMEWw//SVUtnAF9gud5ICaIIZJ2I2fK5OIzDPgFnIm4p6XAHVVqsUPGK0135RGC 0mMii/UtNef9uFyrc97eGWFI3u9KVSXaQn4kCnRbPiUpqOGnsc56Wrb+syeh/n3l GXlfKYpSY5+fgNSwhhLvl4WHok6OOLgzm5crbgTNxWBFUkOVkUmyHD3DGflD5OyG M9O8QLeru0xt770QjlkBLk9f6htqJ7rvClDvkgCRoXHqhgWpQTTgbs5pdU8/3hWW uNhO4LfcOUQb0gKgaJ9TeZCL1U2anJTg9DHQBzwWPZsMES5LY3NHWNt4J/Z/SLfN Mn+O8BOOhQB1Lu5JKeIrBJ44IS9jk2wO8VOfGFoHLwzssaTE1NS1xbo6nmT7sj08 H0J8LKd1ADnnXvXwOyZoozZ3qALRRN47CZd5LCCfVNsjzNT4V2VPZp1JFFOUqpRS vk0S9Mgz+rd7VNzjMVfiMhl+VpwlZmAVhwmoOHGbtuUM0XBInjT1hsl/U1GevNtQ l8W8PD7zhdVqQF5ioQE2SChoYoFtbrT+Pr2r1hv7lS1cWng8P+qx/FXaYEcmphhE QQetx719pBYjBG5DK32Irb7wE0U1YDb148hiar8CAaAdKT/vVru0AFHG0Acq3Ot0 fIrbP+YoUQbMwf4GaamdmIP+MO3RojcMit6ZQGjjF8C0v1UGqk8= =1k2X -----END PGP SIGNATURE----- --===============5568494826384715101==--