PREFERRED_VERSION_virtual/..

PREFERRED_VERSION_virtual/..

[Andreas Müller]

Hi,

In meta-gumstix I am working on a central include-file where I can
switch kernel-sources/-versions at one single place.

For this I need PREFERRED_VERSION_virtual/... working.

Is there a specific reason why this is not implemented or would it
cause huge efforts to implement?

Andreas

Re: PREFERRED_VERSION_virtual/..

[Phil Blundell]

On Thu, 2012-09-06 at 12:45 +0200, Andreas Müller wrote:
> In meta-gumstix I am working on a central include-file where I can
> switch kernel-sources/-versions at one single place.
> 
> For this I need PREFERRED_VERSION_virtual/... working.
> 
> Is there a specific reason why this is not implemented or would it
> cause huge efforts to implement?

Well, it's inherently meaningless: virtuals don't have any version
number, only concrete packages do, and it's entirely possible that the
different providers for a given virtual might have unrelated (whether or
not intersecting) version numbering schemes.  

Why exactly do you want this?

p.

Re: PREFERRED_VERSION_virtual/..

[Andreas Müller]

On Thu, Sep 6, 2012 at 12:47 PM, Phil Blundell <philb@gnu.org> wrote:
> On Thu, 2012-09-06 at 12:45 +0200, Andreas Müller wrote:
>> In meta-gumstix I am working on a central include-file where I can
>> switch kernel-sources/-versions at one single place.
>>
>> For this I need PREFERRED_VERSION_virtual/... working.
>>
>> Is there a specific reason why this is not implemented or would it
>> cause huge efforts to implement?
>
> Well, it's inherently meaningless: virtuals don't have any version
> number, only concrete packages do, and it's entirely possible that the
> different providers for a given virtual might have unrelated (whether or
> not intersecting) version numbering schemes.
>
> Why exactly do you want this?
>
> p.
>
>
Since I spend lot of time testing different kernels, I would like to
have a single location where I can setup which kernel-source/-version
is compiled [1] simply (this file is included by my machine
configuration [2]). Alongside I want to ensure that the
linux-glibc-headers share same version as the kernel [3].

So for my case: I have

* linux-mainline_3.2.bbappend (3.2.19)
* linux-omap_3.5.bb (3.5.0)
* linux-omap_3.6.bb (3.6.0-rc3)
* linux-sakoman_3.2.bb (3.2.0)

Without PREFERRED_VERSION_virtual/.. I cannot select between
linux-omap_3.5.bb and linux-omap_3.6.bb. OK I can use
PREFERRED_VERSION_linux-omap (as I am doing in [2] currently) but if I
select to build linux-mainline, I get complaints that there is no
linux-omap-3.2.9.

Hope that explains what I would like to have this feature...

Andreas

[1] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/recipes-kernel/linux/linux-versions-overo.inc
[2] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/conf/machine/overo.conf
[3] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/recipes-kernel/linux-libc-headers/linux-libc-headers_git.bb
Repl

Re: PREFERRED_VERSION_virtual/..

[Mark Hatle]

On 9/6/12 6:14 AM, Andreas Müller wrote:
> On Thu, Sep 6, 2012 at 12:47 PM, Phil Blundell <philb@gnu.org> wrote:
>> On Thu, 2012-09-06 at 12:45 +0200, Andreas Müller wrote:
>>> In meta-gumstix I am working on a central include-file where I can
>>> switch kernel-sources/-versions at one single place.
>>>
>>> For this I need PREFERRED_VERSION_virtual/... working.
>>>
>>> Is there a specific reason why this is not implemented or would it
>>> cause huge efforts to implement?
>>
>> Well, it's inherently meaningless: virtuals don't have any version
>> number, only concrete packages do, and it's entirely possible that the
>> different providers for a given virtual might have unrelated (whether or
>> not intersecting) version numbering schemes.
>>
>> Why exactly do you want this?
>>
>> p.
>>
>>
> Since I spend lot of time testing different kernels, I would like to
> have a single location where I can setup which kernel-source/-version
> is compiled [1] simply (this file is included by my machine
> configuration [2]). Alongside I want to ensure that the
> linux-glibc-headers share same version as the kernel [3].
>
> So for my case: I have
>
> * linux-mainline_3.2.bbappend (3.2.19)
> * linux-omap_3.5.bb (3.5.0)
> * linux-omap_3.6.bb (3.6.0-rc3)
> * linux-sakoman_3.2.bb (3.2.0)
>
> Without PREFERRED_VERSION_virtual/.. I cannot select between
> linux-omap_3.5.bb and linux-omap_3.6.bb. OK I can use
> PREFERRED_VERSION_linux-omap (as I am doing in [2] currently) but if I
> select to build linux-mainline, I get complaints that there is no
> linux-omap-3.2.9.

This is where preferred provider is used, and then the preferred version can be 
used to select the right version of a given provider.

PREFERRED_PROVIDER_virtual/kernel = "linux-foo"
PREFERRED_VERSION_linux-foo = "3.4"

> Hope that explains what I would like to have this feature...
>
> Andreas
>
> [1] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/recipes-kernel/linux/linux-versions-overo.inc
> [2] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/conf/machine/overo.conf
> [3] http://gitorious.org/schnitzeltony-oe-meta/meta-gumstix/blobs/master/recipes-kernel/linux-libc-headers/linux-libc-headers_git.bb
> Repl
>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
>