All of lore.kernel.org
 help / color / mirror / Atom feed
* Building CentOS based filesystem #yocto
@ 2020-02-24 16:15 Bill.Kulp
  2020-02-24 16:28 ` [yocto] " Alexander Kanavin
  2020-02-24 17:09 ` Richard Purdie
  0 siblings, 2 replies; 4+ messages in thread
From: Bill.Kulp @ 2020-02-24 16:15 UTC (permalink / raw)
  To: yocto

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

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://github.com/meta-debian/meta-debian , 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.
Thank you!

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [yocto] Building CentOS based filesystem #yocto
  2020-02-24 16:15 Building CentOS based filesystem #yocto Bill.Kulp
@ 2020-02-24 16:28 ` Alexander Kanavin
  2020-02-24 17:09 ` Richard Purdie
  1 sibling, 0 replies; 4+ messages in thread
From: Alexander Kanavin @ 2020-02-24 16:28 UTC (permalink / raw)
  To: Bill.Kulp; +Cc: yocto

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

If a customer wants CentOS, they should be using CentOS. I really wouldn't
want to embark on that path, you'll be constantly dealing with
incompatibilities and incorrect assumptions.

Alex

On Mon, 24 Feb 2020 at 17:16, <Bill.Kulp@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://github.com/meta-debian/meta-debian, 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.
> Thank you! 
>

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [yocto] Building CentOS based filesystem #yocto
  2020-02-24 16:15 Building CentOS based filesystem #yocto Bill.Kulp
  2020-02-24 16:28 ` [yocto] " Alexander Kanavin
@ 2020-02-24 17:09 ` Richard Purdie
  2020-02-25  7:31   ` [EXT] " Heinz Wrobel
  1 sibling, 1 reply; 4+ messages in thread
From: Richard Purdie @ 2020-02-24 17:09 UTC (permalink / raw)
  To: Bill.Kulp, yocto

On Mon, 2020-02-24 at 08:15 -0800, Bill.Kulp@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://github.com/meta-debian/meta-debian, 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


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [EXT] Re: [yocto] Building CentOS based filesystem #yocto
  2020-02-24 17:09 ` Richard Purdie
@ 2020-02-25  7:31   ` Heinz Wrobel
  0 siblings, 0 replies; 4+ messages in thread
From: Heinz Wrobel @ 2020-02-25  7:31 UTC (permalink / raw)
  To: Bill.Kulp, yocto

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.Kulp@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.Kulp@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&amp;data=02%7C01%7CHeinz.Wrobel%40n
> xp.com%7C82e3e08139084728484208d7b94c47b0%7C686ea1d3bc2b4c6fa92cd99c5c301635%7C0%7C0%7C637181609586689793&amp;sdata=dLRkBIpqahVwyBNEUhHeT9ekyCYq0yn4mm%2Fl%2BPainQc%3D&amp;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


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2020-02-25  7:31 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-02-24 16:15 Building CentOS based filesystem #yocto Bill.Kulp
2020-02-24 16:28 ` [yocto] " Alexander Kanavin
2020-02-24 17:09 ` Richard Purdie
2020-02-25  7:31   ` [EXT] " Heinz Wrobel

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.