Building a package of one version for target, and another version for native

Building a package of one version for target, and another version for native

[Robert Tiemann]

Hi!

Is it possible to build packages so that the versions for native and
target builds are different (using dunfell here)?

My goal is to use gnutls and nettle in the version as shipped with
dunfell (3.6.12 and 3.5.1, respectively) for the native tool chain,
but a more recent version for the target. Simply upgrading the version
for both, native and target, works, but then all RPM packages get
rebuilt (not taken from sstate), and this is a problem for me.

So, I have added recipes for upgraded versions of gnutls and nettle to
my own layer, and in my layer's distro configuration I tried

PREFERRED_VERSION_gnutls-native = "3.6.12"
PREFERRED_VERSION_nettle-native = "3.5.1"

and

PREFERRED_VERSION_pn-gnutls-native = "3.6.12"
PREFERRED_VERSION_pn-nettle-native = "3.5.1"

and also

PREFERRED_VERSION_gnutls-native_forcevariable = "3.6.12"
PREFERRED_VERSION_nettle-native_forcevariable = "3.5.1"

and

PREFERRED_VERSION_pn-gnutls-native_forcevariable = "3.6.12"
PREFERRED_VERSION_pn-nettle-native_forcevariable = "3.5.1"

but all of these seem to get ignored. I always end up with the more
recent versions for the native builds.

What is it what I am missing here?

Cheers,
Robert

Re: [poky] Building a package of one version for target, and another version for native

[Peter Kjellerstedt]

> -----Original Message-----
> From: poky@lists.yoctoproject.org <poky@lists.yoctoproject.org> On Behalf
> Of Robert Tiemann
> Sent: den 28 januari 2022 11:43
> To: poky@lists.yoctoproject.org
> Subject: [poky] Building a package of one version for target, and another
> version for native
> 
> Hi!
> 
> Is it possible to build packages so that the versions for native and
> target builds are different (using dunfell here)?
> 
> My goal is to use gnutls and nettle in the version as shipped with
> dunfell (3.6.12 and 3.5.1, respectively) for the native tool chain,
> but a more recent version for the target. Simply upgrading the version
> for both, native and target, works, but then all RPM packages get
> rebuilt (not taken from sstate), and this is a problem for me.
> 
> So, I have added recipes for upgraded versions of gnutls and nettle to
> my own layer, and in my layer's distro configuration I tried
> 
> PREFERRED_VERSION_gnutls-native = "3.6.12"
> PREFERRED_VERSION_nettle-native = "3.5.1"

That's the correct format. Not sure why it doesn't work though. 
It might have to do with how BBCLASSEXTEND works.

> 
> and
> 
> PREFERRED_VERSION_pn-gnutls-native = "3.6.12"
> PREFERRED_VERSION_pn-nettle-native = "3.5.1"
> 
> and also
> 
> PREFERRED_VERSION_gnutls-native_forcevariable = "3.6.12"
> PREFERRED_VERSION_nettle-native_forcevariable = "3.5.1"
> 
> and
> 
> PREFERRED_VERSION_pn-gnutls-native_forcevariable = "3.6.12"
> PREFERRED_VERSION_pn-nettle-native_forcevariable = "3.5.1"
> 
> but all of these seem to get ignored. I always end up with the more
> recent versions for the native builds.
> 
> What is it what I am missing here?
> 
> Cheers,
> Robert	

One solution is to also copy the gnutls_3.6.12.bb recipe to 
your own layer and rename it to gnutls-native_3.6.12.bb and 
add an inherit of native to it.

Another solution is to instead use a bbappend. It should be 
a versioned bbapend, i.e., gnutls_3.6.12.bbappend so in case 
you or someone else decide to upgrade to a newer version of 
Dunfell (which has a newer version of gnutls), you will get 
a build error and know you have to take care of it. Something 
like this should do it:

PV_class-target = "3.6.14"

SRC_URI_append_class-target = " \
    file://0001-Modied-the-license-to-GPLv2.1-to-keep-with-LICENSE-f.patch \
    file://CVE-2020-24659.patch \
    file://CVE-2021-20231.patch \
    file://CVE-2021-20232.patch \
"

MD5SUM = "a23900f14980a467bdce3a0fd31dfa18"
MD5SUM_class-target = "..."
SRC_URI[md5sum] = "${MD5SUM}"
SHA256SUM = "bfacf16e342949ffd977a9232556092c47164bd26e166736cf3459a870506c4b"
SHA256SUM_class-target = "..."
SRC_URI[sha256sum] = "${SHA256SUM}"

and any other adaptations that are needed to cater to differences 
between the two recipe versions. The patches you can pick up from 
dunfell-23.0.9 or later.

//Peter

Re: [poky] Building a package of one version for target, and another version for native

[Robert Tiemann]

On 1/28/22 20:18, Peter Kjellerstedt wrote:
>> -----Original Message-----

Hi, and apologies for my very slow reply.

>> PREFERRED_VERSION_gnutls-native = "3.6.12"
>> PREFERRED_VERSION_nettle-native = "3.5.1"
>
> That's the correct format. Not sure why it doesn't work though.
> It might have to do with how BBCLASSEXTEND works.

Thank you very much, this was the crucial hint. Removal of the
BBCLASSEXTEND lines from my copied and upgraded package recipes did the
job. The native versions are built from the original recipes now, target
packages are built from the new ones.

> One solution is to also copy the gnutls_3.6.12.bb recipe to
> your own layer and rename it to gnutls-native_3.6.12.bb and
> add an inherit of native to it.

This didn't work at first, and after some editing I ended up with
gnutls-native-native. :-D

> //Peter

Best regards,
Robert