Hi, we at NXP did something like this for the Automotive Linux BSP already a number of years ago.
We are using Yocto to optionally also build a fairly reproducible Ubuntu 16 or 18 image for customer scenarios. "fairly" => We don't try to do full binary equivalence across builds. We aim for functional equivalence and a reliable build procedure. This however is nontrivial to do and maintain. We decided to go there for specific reasons that were in a nutshell: We needed a mix of special elements we maintain in Yocto integrated with a Ubuntu rootfs in an automated way, and we also did not want to require sudo privileges from anyone using the BSP. Note that we do not dare build Ubuntu *content* using Yocto recipes. We build up Yocto packages with the Ubuntu rootfs from available Ubuntu content with a recipe that makes use of pseudo/qemu-user/apt and then build a final image from this and additional Yocto packages and more pseudo/qemu-user/apt invocations. Something like this requires significant updates/fixes/improvements to pseudo and patches/fixes to qemu-user. Those patches are IMHO stable and are moved from version to version. I wish all that would be upstreamed so that less patches need to be maintained, but that is another topic. A good amount of extra magic using a special class and Ubuntu related recipes is also needed. As we are moving to Zeus currently, the amount of magic in our Ubuntu related recipes and classes very substantially diminishes for the next release built upon Zeus, but for sure a good amount of dangerous magic remains. A key problem with such an approach is a need to make educated guesses about who provides what in which version when you really wouldn't know about it yet. You need to "pre-guess" PREFERRED_RPROVIDERS and RDEPENDS based on content that is effectively recipe and image dependent. If there was a stable way to assess and update PREFERRED_[R|]PROVIDERS *after* all recipes have been parsed, a lot of the fragile magic could disappear and the remaining magic would be much more obvious and automatically right. I don't see such a way though unless you really want to mutilate and second guess Yocto. You also need to ensure that the Yocto packages are built with a glibc that doesn't conflict with the target Ubuntu glibc, or package integration won't lead to working tools on the target. This is solved going forward by having appropriate glibc recipes that are "good enough" on the Yocto side, too. Richard has a point. If you want to go into such a direction anyway, think hard, and think twice. I have been there. Something like that can be done, it is convenient once it works, but it is absolutely non-trivial to go there. If you want to reuse our ideas on that anyway, wait for the next Zeus based release of the NXP Automotive Linux BSP, as it will be much cleaner. BR, Heinz -----Original Message----- From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On Behalf Of Richard Purdie via Lists.Yoctoproject.Org Sent: Monday, February 24, 2020 6:09 PM To: bill.k...@azuresummit.com; yocto@lists.yoctoproject.org Cc: yocto@lists.yoctoproject.org Subject: [EXT] Re: [yocto] Building CentOS based filesystem #yocto Caution: EXT Email On Mon, 2020-02-24 at 08:15 -0800, bill.k...@azuresummit.com wrote: > Hello! I am currently using Yocto with default Poky distro. A > customer would like a CentOS-based filesystem, and I am wondering if > this is possible using Yocto? > > My initial thought is to imitate > https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith > ub.com%2Fmeta-debian%2Fmeta-debian&data=02%7C01%7CHeinz.Wrobel%40n > xp.com%7C82e3e08139084728484208d7b94c47b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637181609586689793&sdata=dLRkBIpqahVwyBNEUhHeT9ekyCYq0yn4mm%2Fl%2BPainQc%3D&reserved=0, > creating Bitbake recipes to directly download CentOS binary .rpm packages, > or to download and build CentOS .rpm source packages. > > Does this approach seem feasible? Would it be fairly straightforward, > or are there pitfalls to beware of? I would really appreciate any > insight. If you want CentOS, use CentOS. By definition anything else is playing catchup and will never quite match. We've looked into spec generation before but the worlds are quite different, we cross compile, spec files do not. "Our" output is therefore always going to be different from say the spec file built on target in a native build. We've tried experiments with this before and ended up deciding we should accept Yocto Project is Yocto Project, its not trying to be anything else. Cheers, Richard
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#48594): https://lists.yoctoproject.org/g/yocto/message/48594 Mute This Topic: https://lists.yoctoproject.org/mt/71529286/21656 Mute #yocto: https://lists.yoctoproject.org/mk?hashtag=yocto&subid=6691583 Group Owner: yocto+ow...@lists.yoctoproject.org Unsubscribe: https://lists.yoctoproject.org/g/yocto/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
