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

Thu Feb 13 07:49:10 PST 2014

Hey Pascal,

[Re: [yocto] [meta-selinux][PATCH 0/4] Begin mingrating bbappends to use wildcards in place of version numbers.] On 14.02.13 (Thu 10:33) Pascal Ouyang wrote:

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

Yeah, I completely agree in general.  In the specific cases we've been
looking at so far with Phil's stuff, though, I don't think that's
necessary or particularly desirable.  Take, for example, the libcgroup
change.  That bbappend has been unchanged since it was introduced and
isn't likely to change based on version-specific changes in libcgroup
upstream, so that's definitely a good candidate for a wildcard append.

Without a doubt, though, there will be cases that warrant a
version-specific bbappend.

-J.

> 
> 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 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
> >>>>>>
> >>>>>
> >>>>>
> >>>
> >>
> >>
> >>
> >>
> >>_______________________________________________
> >>yocto mailing list
> >>yocto at yoctoproject.org
> >>https://lists.yoctoproject.org/listinfo/yocto
> 
> 
-- 
-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/20140213/d681e163/attachment.pgp>