On Mon, 7 Oct 2024 at 07:06, Aleksandar Nikolic via
lists.yoctoproject.org
<aleksandar.nikolic010=gmail.com@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).

I am of the same opinion and even though pre-built binaries do come in handy in some occasions, IMHO they bring a lot of other issues along and it's not worth it. Just wanted to hear other opinions on the mailing list.

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