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: [email protected]
signature.asc
Description: Digital signature
_______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
