Re: [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.

[Pascal Ouyang <xin.ouyang@windriver.com>]

于 14-2-13 上午8:18, Joe MacDonald 写道:
> [Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.] On 14.02.12 (Wed 09:57) Randy MacLeod wrote:
>
>> On 14-02-11 09:54 PM, Philip Tricca wrote:
>>> On 02/11/2014 08:15 PM, Joe MacDonald wrote:
>>>> [Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends
>>>> to use wildcards in place of version numbers.] On 14.02.11 (Tue
>>>> 15:11) Randy MacLeod wrote:
>>>>
>>>>> On 14-02-06 10:09 PM, Philip Tricca wrote:
>>>>>> The current trend in OE recipes seems to use a wildcard in
>>>>>> place of version numbers for bbappends. AFAIK this is a
>>>>>> relatively new feature but a welcome one. This is a sort of RFC
>>>>>> in that I think it's probably best for meta-selinux to use this
>>>>>> mechanism to keep from having to rename bbappends everytime
>>>>>> something in oe-core changes. I guess the right way to
>>>>>> implement this is to change the bbappends in meta-selinux when
>>>>>> the version numbers change upstream.
>>
>> I'm convinced that we should give this a try.
>> If there are cases where the wildcard bbappend doesn't work, we can
>> always use explicit versions and add a comment explaining why
>> the wildcard isn't used.

Generally, wildcard bbappends should be applied to config parts to 
enable/disable selinux, such as "inherit enable-selinux".

If there are selinux patches(backport, or poky only), we should also 
leave a version bbappend.

Thanks all. :)

- Pascal

>
> Since this sounds like consensus:
>
> git push origin HEAD:master
> Counting objects: 24, done.
> Delta compression using up to 4 threads.
> Compressing objects: 100% (12/12), done.
> Writing objects: 100% (16/16), 1.55 KiB, done.
> Total 16 (delta 10), reused 0 (delta 0)
> To git@git.yoctoproject.org:meta-selinux
>     1326699..05a0c6c  HEAD -> master
>
>
> :-)
>
> Thanks, Phil.
>
> -J.
>
>>
>> ../ Randy
>>
>>>>>>
>>>>>
>>>>> Hi Philip,
>>>>>
>>>>> This might work out but I'm somewhat attached to the manual
>>>>> process.
>>>>
>>>> It's a change I'd been advocating for quite some time now.
>>>> (Actually, it was something I was somewhat surprised wasn't
>>>> possible when I first came to bitbake in general, so at least to me
>>>> this change seems pretty sensible.)
>>>>
>>>> The risks you outline are real, but historically this hasn't shown
>>>> itself to be a significant problem so far.  The types of things
>>>> this'll hit on are characterized well in Phil's RFC set.  Stuff
>>>> like sudo and libcgroup which require bbappends but the contents
>>>> haven't had any meaningful change since the stone age.  :-)
>>>>
>>>> I think this is actually a win for meta-selinux in terms of
>>>> reducing the number of commits like f0adb425.
>>>>
>>>> I've already staged the proposed change in my tree and it seems
>>>> happy, so I'm inclined to merge it, FWIW.
>>>
>>> I appreciate both sides of this being represented. I agree with Joe
>>> that it's an obvious fit for simple bbappends that require little more
>>> than --(enable|with)-selinux. The more involved bbappends may be
>>> better suited to manual version number changes.
>>>
>>> If any of the recipes from this set fall into the later category I
>>> won't object to dropping them and favoring the process manual. But as
>>> Joe points out, I think this approach is a given for the likes of
>>> sudo, libcgroup etc.
>>>
>>> Thanks,
>>> Philip
>>>
>>>>
>>>> -J.
>>>>
>>>>> Manual matching shows that someone is: - paying attention, -
>>>>> fixed the bbappend version number, - gotten someone else to
>>>>> review, - hopefully built the software for at least one arch, -
>>>>> hopefully tested run-time for at least one arch.
>>>>>
>>>>> With a wildcard matching rule, there will be times when the
>>>>> underlying package has changed and then the recipe changes and
>>>>> perhaps code patches still apply but are to some extent broken.
>>>>> Have people accepted this as a possible outcome that they believe
>>>>> will be rare? Have you tried your approach with a few different
>>>>> oe-core baselines such as dora, random, master?
>>>>>
>>>>> I'm not agaist this change but I'm trying to be sure that people
>>>>> agree that it's a good approach and that we've tested the idea
>>>>> with some historical changes.
>>>>>
>>>>> Thanks,
>>>>>
>>>>> ../Randy
>>>>>
>>>>>
>>>>>> Philip Tricca (4): busybox: Use wildcard for version number in
>>>>>> busybox bbappend. libcgroup: Use wildcard for version number in
>>>>>> libcgroup bbappend. sudo: Use wildcard for version number in
>>>>>> sudo bbappend. libxcb: Use wildcard for version number in
>>>>>> libxcb bbappend.
>>>>>>
>>>>>> recipes-core/busybox/busybox_%.bbappend        |   87
>>>>>> ++++++++++++++++++++++++
>>>>>> recipes-core/busybox/busybox_1.21.1.bbappend   |   87
>>>>>> ------------------------
>>>>>> recipes-core/libcgroup/libcgroup_%.bbappend    |   12 ++++
>>>>>> recipes-core/libcgroup/libcgroup_0.38.bbappend |   12 ----
>>>>>> recipes-extended/sudo/sudo_%.bbappend          |    3 +
>>>>>> recipes-extended/sudo/sudo_1.8.8.bbappend      |    3 -
>>>>>> recipes-graphics/xcb/libxcb_%.bbappend         |    8 +++
>>>>>> recipes-graphics/xcb/libxcb_1.9.3.bbappend     |    8 --- 8
>>>>>> files changed, 110 insertions(+), 110 deletions(-) create mode
>>>>>> 100644 recipes-core/busybox/busybox_%.bbappend delete mode
>>>>>> 100644 recipes-core/busybox/busybox_1.21.1.bbappend create mode
>>>>>> 100644 recipes-core/libcgroup/libcgroup_%.bbappend delete mode
>>>>>> 100644 recipes-core/libcgroup/libcgroup_0.38.bbappend create
>>>>>> mode 100644 recipes-extended/sudo/sudo_%.bbappend delete mode
>>>>>> 100644 recipes-extended/sudo/sudo_1.8.8.bbappend create mode
>>>>>> 100644 recipes-graphics/xcb/libxcb_%.bbappend delete mode
>>>>>> 100644 recipes-graphics/xcb/libxcb_1.9.3.bbappend
>>>>>>
>>>>>
>>>>>
>>>
>>
>>
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto


-- 
- Pascal