From: Mark Hatle <mark.hatle@windriver.com>
To: <openembedded-core@lists.openembedded.org>
Subject: Re: PREFERRED_VERSION_virtual/..
Date: Thu, 6 Sep 2012 12:43:15 -0500 [thread overview]
Message-ID: <5048E0B3.60604@windriver.com> (raw)
In-Reply-To: <CALbNGRRpab2YJWZbVJvLyXV8npxGW9Gv4vajTmDQ_dJOzJXqiQ@mail.gmail.com>
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
>
prev parent reply other threads:[~2012-09-06 17:55 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-06 10:45 PREFERRED_VERSION_virtual/ Andreas Müller
2012-09-06 10:47 ` PREFERRED_VERSION_virtual/ Phil Blundell
2012-09-06 11:14 ` PREFERRED_VERSION_virtual/ Andreas Müller
2012-09-06 17:43 ` Mark Hatle [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5048E0B3.60604@windriver.com \
--to=mark.hatle@windriver.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox