Alternative to _git.bb convention for unstable versions?

Alternative to _git.bb convention for unstable versions?

[keith.derrick]

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

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.


Currently I have somepackage_1.0.bb and somepackage_git.bb which are working fine.


However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.


If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.


I'm considering instead using either "somepackage-unstable.bb" or "somepackage-devel.bb" instead of "sompackage_git.bb". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.


However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.


Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?


Thanks

Keith Derrick


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

Re: Alternative to _git.bb convention for unstable versions?

[Martin Jansa]

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

You can easily add .inc file which will set all the PREFERRED_VERSIONs for
all components you need and then the users will just add an "require" of
this .inc files to their local.conf.

"somepackage-unstable.bb" or "somepackage-devel.bb" this will make it 2
different components - not 2 different versions of the same component -
which makes this much more complicated, you'll need PREFERRED_PROVIDERs for
every dependency and in the end you will need to make sure that whole build
is using the same set of providers, because if

A depends on somepackage-unstable
B depends on A and somepackage-devel

then building B will fail in prepare-recipe-sysrooot, because A will pull
somepackage-unstable which will probably conflict with somepackage-devel by
providing the same files (in just different version). You can see how
openssl10 and openssl "worked" if you build didn't use the same one for all
the recipes.

Cheers,

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick <keith.derrick@lge.com> wrote:

> I am currently creating a new layer (which will eventually be made
> generally available). I need to provide both a versioned recipe, and an
> "unstable"  one.
>
>
> Currently I have somepackage_1.0.bb and somepackage_git.bb which are
> working fine.
>
>
> However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1")
> requires the use of PREFERRED_VERSION in either local.conf or
> a distro.conf. I've tried putting it in the image files, and that doesn't
> work.
>
>
> If you are not creating your own DISTRO, and instead just adding the layer
> to a straight poky/meta build, you seem to be pretty much stuck with adding
> 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants)
> to local.conf. I'd rather not require that of users of the layer.
>
>
> I'm considering instead using either "somepackage-unstable.bb" or "
> somepackage-devel.bb" instead of "sompackage_git.bb". This allows a
> simple selection of either  RDEPENDS = "somepackage" or RDEPENDS =
> "somepackage-devel" to add the desired one to an image.
>
>
> However, neither "-devel" or "-unstable" have the right feel for the
> suffix. If, for example, you are picking up an older commit (between
> versions  say) it might well be completely stable.
>
>
> Does the community have a naming convention for this type of recipe?
> Failing that, is there somewhere else in the met-data the PREFERRED_VERSION
> statement can go other than a configuration file?
>
>
> Thanks
>
> Keith Derrick
>
>
> --
> _______________________________________________
> yocto mailing list
> yocto@yoctoproject.org
> https://lists.yoctoproject.org/listinfo/yocto
>

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

Re: Alternative to _git.bb convention for unstable versions?

[keith.derrick]

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

Thanks Martin.

I was trying to avoid everyone in my org having to add anything manually to their local.conf (we will be using the _git version) – and dealing with the “help me” emails whenever they forgot.

I was thinking that you would want one or the other, but I suppose if there’s a way to screw up, users will find it ☹

Eventually, we’ll switch our build to a custom DISTRO and the problem will go away. Just wish there was somewhere else the PREFERRED_VERSION statements could go.



From: Martin Jansa <martin.jansa@gmail.com>
Date: Friday, September 13, 2019 at 8:35 AM
To: "Keith Derrick/LGEUS Advanced Platform(keith.derrick@lge.com)" <keith.derrick@lge.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: [yocto] Alternative to _git.bb convention for unstable versions?

You can easily add .inc file which will set all the PREFERRED_VERSIONs for all components you need and then the users will just add an "require" of this .inc files to their local.conf.

"somepackage-unstable.bb<http://somepackage-unstable.bb>" or "somepackage-devel.bb<http://somepackage-devel.bb>" this will make it 2 different components - not 2 different versions of the same component - which makes this much more complicated, you'll need PREFERRED_PROVIDERs for every dependency and in the end you will need to make sure that whole build is using the same set of providers, because if

A depends on somepackage-unstable
B depends on A and somepackage-devel

then building B will fail in prepare-recipe-sysrooot, because A will pull somepackage-unstable which will probably conflict with somepackage-devel by providing the same files (in just different version). You can see how openssl10 and openssl "worked" if you build didn't use the same one for all the recipes.

Cheers,

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick <keith.derrick@lge.com<mailto:keith.derrick@lge.com>> wrote:

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.



Currently I have somepackage_1.0.bb<http://somepackage_1.0.bb> and somepackage_git.bb<http://somepackage_git.bb> which are working fine.



However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.



If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.



I'm considering instead using either "somepackage-unstable.bb<http://somepackage-unstable.bb>" or "somepackage-devel.bb<http://somepackage-devel.bb>" instead of "sompackage_git.bb<http://sompackage_git.bb>". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.



However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.



Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?



Thanks

Keith Derrick


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto

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

Re: Alternative to _git.bb convention for unstable versions?

[Erik Hoogeveen]

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

Hello Keith,

I’m not sure if this is any good, I’m not all that experienced with Yocto.
But would it be an idea to add PREFERRED_VERSION ?= “1.0” in your layer.conf to provide your users with a sane default?

Cheers,
Erik
On 13 Sep 2019, 18:00 +0200, keith.derrick <keith.derrick@lge.com>, wrote:
Thanks Martin.

I was trying to avoid everyone in my org having to add anything manually to their local.conf (we will be using the _git version) – and dealing with the “help me” emails whenever they forgot.

I was thinking that you would want one or the other, but I suppose if there’s a way to screw up, users will find it ☹

Eventually, we’ll switch our build to a custom DISTRO and the problem will go away. Just wish there was somewhere else the PREFERRED_VERSION statements could go.



From: Martin Jansa <martin.jansa@gmail.com>
Date: Friday, September 13, 2019 at 8:35 AM
To: "Keith Derrick/LGEUS Advanced Platform(keith.derrick@lge.com)" <keith.derrick@lge.com>
Cc: "yocto@yoctoproject.org" <yocto@yoctoproject.org>
Subject: Re: [yocto] Alternative to _git.bb convention for unstable versions?

You can easily add .inc file which will set all the PREFERRED_VERSIONs for all components you need and then the users will just add an "require" of this .inc files to their local.conf.

"somepackage-unstable.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage-unstable.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221106440&sdata=0imtxCVvoxQCNauLifAjpvC%2FsXWQtLoznSEdNhh%2FelI%3D&reserved=0>" or "somepackage-devel.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage-devel.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221116451&sdata=apC3OqdaU3XDEHJKbc58XNhMSBEFMKgorcKtd1U%2Ftqc%3D&reserved=0>" this will make it 2 different components - not 2 different versions of the same component - which makes this much more complicated, you'll need PREFERRED_PROVIDERs for every dependency and in the end you will need to make sure that whole build is using the same set of providers, because if

A depends on somepackage-unstable
B depends on A and somepackage-devel

then building B will fail in prepare-recipe-sysrooot, because A will pull somepackage-unstable which will probably conflict with somepackage-devel by providing the same files (in just different version). You can see how openssl10 and openssl "worked" if you build didn't use the same one for all the recipes.

Cheers,

On Fri, Sep 13, 2019 at 5:27 PM keith.derrick <keith.derrick@lge.com<mailto:keith.derrick@lge.com>> wrote:

I am currently creating a new layer (which will eventually be made generally available). I need to provide both a versioned recipe, and an "unstable"  one.



Currently I have somepackage_1.0.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage_1.0.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221126468&sdata=4Li0Hl3yPEh6pNxBuVno3pZFkJbFkSVVGKlM4AabY50%3D&reserved=0> and somepackage_git.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage_git.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221136479&sdata=1K%2BlEwtPd6VUNMJNfPxCGO2hNtcnigU3MEnuHTDUZpw%3D&reserved=0> which are working fine.



However, using the "_git" approach (with DEFAULT_PREFERENCE = "-1") requires the use of PREFERRED_VERSION in either local.conf or a distro.conf. I've tried putting it in the image files, and that doesn't work.



If you are not creating your own DISTRO, and instead just adding the layer to a straight poky/meta build, you seem to be pretty much stuck with adding 3 PREFERRED_VERSION statements (target, -native, and nativesdk- variants) to local.conf. I'd rather not require that of users of the layer.



I'm considering instead using either "somepackage-unstable.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage-unstable.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221146485&sdata=9VAs45eFE4%2BAt2g0IsfEjIzdbgoJseLmhjUFDAPEThc%3D&reserved=0>" or "somepackage-devel.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsomepackage-devel.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221156502&sdata=q2hpeGg01Sz9sL0vqwO2CK829DWMgqGpvZ0YSbzgcws%3D&reserved=0>" instead of "sompackage_git.bb<https://nam02.safelinks.protection.outlook.com/?url=http%3A%2F%2Fsompackage_git.bb&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221166495&sdata=R5oIMlFzkBDJa4MA%2FRmmrBo%2BXmmg0MJzA6AjaTRRy2o%3D&reserved=0>". This allows a simple selection of either  RDEPENDS = "somepackage" or RDEPENDS = "somepackage-devel" to add the desired one to an image.



However, neither "-devel" or "-unstable" have the right feel for the suffix. If, for example, you are picking up an older commit (between versions  say) it might well be completely stable.



Does the community have a naming convention for this type of recipe? Failing that, is there somewhere else in the met-data the PREFERRED_VERSION statement can go other than a configuration file?



Thanks

Keith Derrick


--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org<mailto:yocto@yoctoproject.org>
https://lists.yoctoproject.org/listinfo/yocto<https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyocto&data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221176518&sdata=lIcq2w6g21PRyQQSz5XlIA8r9h7RfmG25yeQBkzJO7o%3D&reserved=0>
--
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://nam02.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.yoctoproject.org%2Flistinfo%2Fyocto&amp;data=02%7C01%7C%7C525f37037f094d9a306608d738637a54%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637039872221216539&amp;sdata=zCqiT9pNZMDJ8vyCLPoLW1lw1v2ovRJGFllMNH1bTIo%3D&amp;reserved=0

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