于 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 g...@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
_______________________________________________
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
