On Mon, 7 Oct 2024 at 07:06, Aleksandar Nikolic via lists.yoctoproject.org <aleksandar.nikolic010=gmail....@lists.yoctoproject.org> wrote: > 1) When I build a recipe previously not installed in my image and want to > install it during runtime, the dnf install command fails, saying that the > package's dependencies are not met (see [2] for more info). This is fine, as > I can see that the tmp/deploy/rpm directory does not contain all of the > package's dependencies nor the dependencies' WORKDIRs contain the deploy-rpms > directory. Is this behavior correct? Shouldn't building a recipe also lead > that all of its dependencies are not just built but also packaged and put > into the tpm/deploy/rpm directory (the same as with building the image > containing the package in question)?
The default behavior is that bitbake runs the absolute minimum of tasks needed to complete the task you specify (in this case, producing the rpm). Making a vim rpm requires only do_package of its dependencies, but not their do_package_write_rpm. If you want all dependent rpms too, this is easily done with: bitbake --runall package_write_rpm vim > 2) Is there an official, stable, and not some hacky way to install already > pre-built packages during the build and not later during runtime? So instead > of building from source or from the sstate-cache, to provide a URL to a > webserver holding packages, which would then be pulled and installed (if I am > not wrong Isar does this)? If you ask me, pulling pre-built packages into a yocto image is in itself a horrible hack that goes against yocto philosophy, and I would not want yocto to help that or support it in any way. We build from source. Isar can do what it wants, but I don't have to like or support that. There's a separate question of pulling pre-built *binaries* that sometimes come in .rpm archives and repackaging them with recipes, which is sort of supported if you list the rpm in SRC_URI (bitbake will then fetch/unpack/repackage), but I don't like that either for different reasons (vendor blobs are evil). > 3) Is enabling and using the package runtime management recommended and > encouraged when it comes to Yocto running on actual devices and not during a > development phase? IMHO we are talking about embedded devices here, with > little or no user interaction, with secure boot enabled, atomic updates, etc. > and having a package management system such as dnf or apt is cool, but is > also kind of brittle (a simple power off during apt update can break the > system). That's exactly correct. Classic package management (rpm/dpkg) was created for the 'Unix workstation' use case where you want to provide as much available disk space as possible to users (so A/B partitioning is a non-starter), and users can easily add things they want to their system. Nobody ever claimed that such mass-upgrade transactions can be safely interrupted by a power outage, and in all likelihood you'll have a half-updated system with an undefined behaviour on the next boot. Alex
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63945): https://lists.yoctoproject.org/g/yocto/message/63945 Mute This Topic: https://lists.yoctoproject.org/mt/108862936/21656 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
