[yocto] linux-yocto 3.0.1 upgrade broke PREFERRED_VERSION setting in BSPs

[Martin Jansa]

On Thu, Aug 18, 2011 at 09:33:17AM -0400, Bruce Ashfield wrote:
> On 11-08-18 01:31 AM, Darren Hart wrote:
> >
> >
> > On 08/17/2011 09:40 PM, Bruce Ashfield wrote:
> >> On 11-08-18 12:11 AM, Bruce Ashfield wrote:
> >>> On 11-08-17 11:23 PM, Darren Hart wrote:
> >>>> We have just rolled out PREFERRED_VERSION="3.0+git%", and these now fail
> >>>> with messages like:
> >>>>
> >>>> NOTE: preferred version 3.0+git% of linux-yocto not available (for item
> >>>> virtual/kernel)
> >>>>
> >>>> I could patch everything really quick to use 3.0.1+git%... but 3.0.2 was
> >>>> just released and I'd have to do it again tomorrow. For 2.6.37, the
> >
> > and 3.0.3 is out...
> >
> >>>> LINUX_VERSION remained the same across point releases. I recommend we do
> >>>> the same for 3.0. I really don't want to have to go through and update
> >>>> all the PREFERRED_VERSIONs in addition to all the SRCREVs everytime a
> >>>> point release comes out.
> >>>
> >>> I made this change due to some other explicit requests about the
> >>> kernel version not being obvious. I don't really see this as a big
> >>> deal, I'm already updating SRCREVs, we are already updating the
> >>> SRCREVs in the meta-* layers .. so I fail to see how this is much
> >>> more load.
> >
> > Don't forget the -rt variant, it is still at 3.0.
> >
> >>> I'd argue that 2.6.37 was a mistake, and you shouldn't even need
> >>> to set the preferred version anymore once the latest kernel works
> >>> for your machines. It will always be selected and you shouldn't
> >>> need to force it. We only needed this during the transition phase,
> >>> and I'm about to change the default in meta-yocto .. so you definitely
> >>> won't need it.
> >>
> >> Another thought on this is that we follow up on the discussion that
> >> we had when I first had to force some boards back to 2.6.37. We drop
> >> all the preferred version manipulations and control this via
> >> DEFAULT_PREFERENCE.
> >>
> >> I can just set DEFAULT_PREFERENCE = -1 in the linux-yocto_<ver>.bb
> >> file, and as machines are tested/validated, they'll just set
> >> the DEFAULT_PREFERENCE_$MACHINE in their recipe/bbappend file. That
> >> saves us all the PREFERRED version fun.
> >
> > It makes a lot more sense to me to specify the kernel to use in the
> > machine config and not allow whatever recipe claim DEFAULT_PREFERENCE
> > for the machines.
> >
> >>
> >> Alternatively, we go back to just setting it to 3.0 and leaving it
> >> there and those folks that don't want to check the tags in the kernel
> >> I can put a comment in the recipe that lets them know the true
> >> version.
> >
> > It is a bit odd to have to specify a version that doesn't match the
> > filename itself. But I guess we already have to do that in part with the
> > "+git%" thing. What is the "%" by the way - is it a wildcard? If so, can
> > we use a wildcard to include point releases?
> 
> It is a wildcard .. I tried briefly to get it to match the point
> release. I had the same problem here, and didn't get the right
> combination to match the point release. I'll look at it more today
> as well .. or if someone knows the matching semantics off the top
> of their head, feel free to speak up! :)

'%' can be used only at the end and it's expected to produce only 1
match 

like 1.0+git%

if there is only one version starting '1.0+git' and we just don't know
exact SRCPV/SRCREV used.

http://git.openembedded.org/cgit.cgi/bitbake/commit/?id=2d1203f446a3527e4d261828b3c10df249119007

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa at gmail.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.yoctoproject.org/pipermail/yocto/attachments/20110818/2ec9521e/attachment.pgp>