On Mon, 7 Oct 2024 at 13:32, Alexander Kanavin via lists.yoctoproject.org <alex.kanavin=gmail....@lists.yoctoproject.org> wrote: > > On Mon, 7 Oct 2024 at 07:06, Aleksandar Nikolic via > lists.yoctoproject.org > <aleksandar.nikolic010=gmail....@lists.yoctoproject.org> wrote: > > 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.
I think this needs a bit of explanation. Ångröm was a binary distro (thanks Koen!). But it existed in a different time and with different development practices. It was great when we had a single monolithic openembedded (OE-Classic) repo. Each recipe had a PR (package revision, the part of the version after the dash), PRs were increased manually when a recipe was changed in a way which changed the packages. Then opkg upgrade would pick up updated packages. Manual work, lots of mistakes, lots of patch conflicts. Then came OE-Core + layers. Basic recipe comes one layer, other layers provide .bbappends. Let each bbappend add a local part to the PR so that each update generates new package to be picked up by the machine. Even more mess, lots of confusion. Let's drop PRs and generate them automatically. Great idea, but it doesn't always work as expected. It's too easy to get the version to go backwards (because of the SRCREV rollback, or because of other recipe changes; or just because you have added a layer with bbappend and then removed it). So the feed has a new package with old PV-PR, the board has an old package with bigger PV-PR, no upgrades, tons of confusion. So, it is possible to create a binary distro on top of Yocto. However one should be very careful with packages and versions, with using a stable set of layers, etc. While the Yocto project probably could provide a feed of build packages, its usefulness would be pretty limited to just oe-core or oe-core + meta-poky (or some other fixed layer configuration). There has been ongoing work to make such configurations work better, but I have doubts that this is going to work as expected on a general scale. So, as much as I like OE, if you are thinking about a binary distro, I think you'd better use some existing purposely binary distro (like Debian, Armbian or something from the RPM world). If you can afford having package management on the device, it's not tightly resource constrained. And thus there is no need to go Yocto 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. That's another good point. One thing is fixing a workstation or a laptop with the KBD and display, where in the worst case one cane boot into single mode or just a shell and play dirty tricks if package management and FS got really broken. On an embedded device there can be no UART, no way to change boot args, etc. So, if the `opkg upgrade` was power-interrupted YMMV. -- With best wishes Dmitry
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#63948): https://lists.yoctoproject.org/g/yocto/message/63948 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] -=-=-=-=-=-=-=-=-=-=-=-
