[OE-core] [PATCH 8/8] [PATCH v2] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.

[Zheng, Ruoqin]

Hi Richard

      eSDK is actually a better technique for developers.  But it’s only suitable for those people who has experience on Yocto Project.

      In the other hand, using dnf-nativesdk in meta-toolchain to customize rootfs is easier fot those people who are familiar with dnf(I think most linux user known it).

      For example, developers finish the OSS build work and provide the toolchain and packages to users. In this case, users do not need to know any knowledge about yocto build system but just how to use dnf to install a rootfs.

      So it can reduce the workload of end-users who need to customize rootfs for their embedded device. At lease, they don’t need to maintain a yocto build server.

--------------------------------------------------
Zheng Ruoqin
Nanjing Fujitsu Nanda Software Tech. Co., Ltd.(FNST)
ADDR.: No.6 Wenzhu Road, Software Avenue,
       Nanjing, 210012, China
MAIL : zhengrq.fnst at cn.fujistu.com


-----Original Message-----
From: Richard Purdie [mailto:richard.purdie at linuxfoundation.org] 
Sent: Monday, June 25, 2018 3:19 PM
To: Zheng, Ruoqin/郑 若钦 <zhengrq.fnst at cn.fujitsu.com>; openembedded-core at lists.openembedded.org
Subject: Re: [OE-core] [PATCH 8/8] [PATCH v2] meta-toolchain: Added dnf-nativesdk into cross-development toolchain.

On Sun, 2018-06-24 at 03:53 +0800, Zheng Ruoqin wrote:
> Add dnf-nativesdk and it's runtime dependence to make dnf work on 
> cross-development environment.
> 
> Signed-off-by: Zheng Ruoqin <zhengrq.fnst at cn.fujitsu.com>

I don't mind adding enough of the changes so that dnf-nativesdk is buildable so some of your other patches can be merged.

I do not want to add dnf-nativesdk to meta-toolchain by default however as there are many people who don't need this there. I'd suggest this is a customisation you'll need to maintain yourselves.

I appreciate why you want to do this, I also believe we have a better technique in the form of the eSDK, where we can use the same tools and the same codebase to build for example a rootfs.

The eSDK use case (a locked sstate cache) is designed so that a user doesn't need to worry about a whole build, or building from scratch.
They can use the same tools everyone else uses and the same workflow and code to bulld a rootfs or a recipe or any workflow. This makes it much more powerful and able to fulfil many different use cases compared to meta-toolchain. In the long run I'd therefore prefer we promote this and use the eSDK as I think it will become our preferred way of handling problems like this.

Cheers,

Richard