Re: [yocto] Yocto Binary Distro

["Aleksandar Nikolic" <aleksandar.nikolic010@gmail.com>]

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

On Mon, Oct 7, 2024 at 01:31 PM, Alexander Kanavin wrote:

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

Thanks, will try this later!

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

Aleksandar

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

[-- Attachment #2: Type: text/html, Size: 3734 bytes --]