Re: [RFC] Documentation: dependencies specification in Bitbake and Debian

[Claudius Heine <ch@denx.de>]

[-- Attachment #1: Type: text/plain, Size: 7320 bytes --]

Hi Silvano,

Quoting Cirujano Cuesta, Silvano (2019-02-06 17:11:40)
> Hi Claudius,
> 
> First of all thank you very much for your quick and valuable feedback!
> 
> On Wed, 2019-02-06 at 16:00 +0100, Claudius Heine wrote:
> > > ## Dependencies table
> > > 
> > > Acronyms:
> > > > Bt = Buildtime
> > > > 
> > > > Rt = Runtime
> > > > Variable           | Bt Bitbake | Bt Debian | Rt Functional | Rt Package |
> > > > ------------------ |:----------:|:---------:|:-------------:|:----------:|
> > > > `DEPENDS`          |     x      |           |               |            |
> > > > `IMAGE_INSTALL`    |     x      |           |      x        |            | > | `IMAGE_PREINSTALL` 
> > > 
> > >             |           |      x        |            |
> > > > `DEBIAN_DEPENDS`   |            |           |               |     x      |
> > 
> > While this graphic looks very simple, that is misguiding.
> > IMO they could lead to a viewpoint that makes really understanding what 
> > is happening more difficult. Bitbake works its dependency magic on task 
> > level and provides DEPENDS to express common task dependencies across 
> > recipes as syntax sugar.
> > 
> > IMAGE_INSTALL + IMAGE_PREINSTALL + DEBIAN_DEPENDS etc. is more about 
> > expressing debian package installation and a bit more. This time it is 
> > isar syntax sugar that puts the entries from IMAGE_INSTALL into DEPENDS.
> > 
> > IMO this sugar, while it makes some things more easy (with big 
> > assumptions), makes some things more difficult (recipes provide multiple 
> > packages). AFAIK this wasn't changed because historic reasons.
> 
> I'm not sure I get your point here...
> 
> My interpretation of your comment is that the table is right, but you would prefer the table not to show the syntactic sugar.
> Mostly to avoid people getting into anti-patterns, I assume.
> Did I get it right?
> 
> The separation between Bitbake dependency at task level and Debian dependency 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.

[...]

> > 
> > > Opposed to `IMAGE_INSTALL`, this doesn't affect any runtime dependencies.
> > > 
> > > 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).
> > > 
> > > ### Bitbake buildtime: `IMAGE_INSTALL`
> > > 
> > > `IMAGE_INSTALL` specifies recipes available in one of the layers that have to be built. > And at the same time specifies that the Debian packages resulting 
> > 
> > from the recipes have to be installed in the image (see 
> > [below](#functional-runtime-image_install) for more information).
> > > 
> > > The logical place to use this variable is an **image** recipe or **configuration** file (distro, layer, ...).
> > 
> > The only places where this is possible.
> 
> 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`
> > > 
> > > This variable provides ["a list of packages that extends the usability of a package"][bb-rrecommends].
> > > 
> > > In ISAR there is only one way to achieve the same:
> > > 
> > > 1. Adding them to the [`Recommends` of the package `debian/control`][pkg-rels] file.
> > 
> > You can do this, but recommended or suggested packages are not installed 
> > per default, but you could change that by overwriting the isar-apt.conf 
> > of the isar-bootstrap-*.bb recipes.
> 
> 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`
> > > 
> > > This variable provides ["the list of packages the recipe creates"][bb-packages].
> > > 
> > > In ISAR there is only one way to achieve the same:
> > > 
> > > 1. Specifying multiple packages in the [`debian/control` file][pkg-control] being provided by a recipe.
> > 
> > Doing so might get problematic because you then cannot use IMAGE_INSTALL 
> > to install those specific packages, because they then will be added to 
> > DEPENDS (as I said IMO bad idea) and have to remove those from DEPENDS 
> > (DEPENDS_remove) and add the correct recipe name manually.
> 
> Well, `DEPENDS` would be needed to get the "Buildtime dependency" (to ensure that the recipe gets executed and the Debian packages get built) and the control file would take care of the "Runtime
> dependency" (to get the functionality in the image or a dependency of a package resolved).
> 
> 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 bad 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

> 
> [2] https://github.com/ilbers/isar/blob/6c5db020b9b837d7b0ce63bfc719f9192e725f26/meta-isar/recipes-app/example-hello/example-hello.bb#L15
> 
> Regards,
>   Silvano
> 
> -- 
> 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/msgid/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

[-- Attachment #2: signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

-----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-----