[oe] [RFC, PATCH] Add minver/maxver to patch.bbclass, update bluez

[Frans Meulenbroeks]

2011/4/25 Tom Rini <tom_rini at mentor.com>

> On 04/25/2011 01:14 PM, Frans Meulenbroeks wrote:
> > 2011/4/25 Tom Rini <tom_rini at mentor.com>
> >
> >> Hey all,
> >>
> >> In digging at some other bluez problems, I found that at least
> >> 4.91 no longer needs the sbc-thumb patch.  But without moving it to the
> >> N versions of bluez4 we have or starting a new inc file for later bluez4
> >> versions, there wasn't a clean way to exclude the patch.  Until now.
> >> Borrowing the minrev/maxrev logic I added minver/maxver patch params
> >> and tested them lightly (the patch is applied on 4.89 and not on
> >> 4.91).  I'm cc'ing Koen here because patch #3 adds 4.91 and make it
> >> default for Angstrom, but all I've done myself is build testing.
> >> It should be safe, based on upstream changelog tho.
> >>
> >> First question should probably be: do we need 9 versions of bluez4? This
> is
> > not too much in line with the version policy the TSC once stipulated and
> > seems also different from the road oe-core and meta-oe are taking.
>
> For bluez4 we could probably drop out 4.31, 4.41 (4.43 seems to
> introduce some startup changes that might require folks to opt-in) and
> then all of the post ones until 4.91, since shr and angstrom would both
> depend on that.  I'd be happy to do that as a follow-up.
>
> > Also personally I'm not too keen on minrev/maxrev. It only makes things
> > again a little bit more complicated.
> > My preference would be to remove the patch from the .inc file and move to
> > the individual bb files
>
> Well, maybe the better answer is a re-worked series to drop out a number
> of older versions, and then it won't be bad to have the patch in a the
> bb files..  Need to think about this.
>

I appreciate it if you would.
To me the analysis of what is needed seems sound.

>
> > My 2 cents.
> >
> > Frans
> >
> > PS: two more cents: it seems somewhat odd that some distro's have a DP =
> 1
> > for more than one version of a recipe. While technically not wrong this
> > looks a little bit odd.
> > Also we seem to have two mechanisms to select a version for a distro. One
> is
> > the DP_distro mechanism the other one is the PREFERRED_VERSION_recipe in
> the
> > conf file
> > It seems to me one should be sufficient
>
> Well, this is in part something the oe-core/meta-oe/etc policy will help
> with since it does have a planned phasing out / removal of the old
> version, so we would have less in the way of "add the latest .z release
> and .z-1 through .z-5 just stick around).
>

Actually the last remark was mostly triggered by the observation that
distro's have two ways to pin a recipe (and actually use both of them).
Having only one mechanism might reduce the chance of causing confusion
and/or mistakes

Frans