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

Wed Feb 12 16:18:05 PST 2014

[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.

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 at 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
> >>>>
> >>>
> >>>
> >
> 
> 
-- 
-Joe MacDonald.
:wq
-------------- 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/20140212/78e3c504/attachment.pgp>