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

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

[Philip Tricca]

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.

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

-- 
1.7.10.4

[meta-selinux][PATCH 1/4] busybox: Use wildcard for version number in busybox bbappend.

[Philip Tricca]

Signed-off-by: Philip Tricca <flihp@twobit.us>

 create mode 100644 recipes-core/busybox/busybox_%.bbappend
 delete mode 100644 recipes-core/busybox/busybox_1.21.1.bbappend

diff --git a/recipes-core/busybox/busybox_%.bbappend b/recipes-core/busybox/busybox_%.bbappend
new file mode 100644
index 0000000..b4935b2
--- /dev/null
+++ b/recipes-core/busybox/busybox_%.bbappend
@@ -0,0 +1,87 @@
+PR .= ".1"
+
+FILES_${PN} += "${libdir}/${PN}"
+
+# We should use sh wrappers instead of links so the commands could get correct
+# security labels
+python create_sh_wrapper_reset_alternative_vars () {
+    # We need to load the full set of busybox provides from the /etc/busybox.links
+    # Use this to see the update-alternatives with the right information
+
+    dvar = d.getVar('D', True)
+    pn = d.getVar('PN', True)
+
+    def create_sh_alternative_vars(links, target, mode):
+        import shutil
+        # Create sh wrapper template
+        fwp = open("busybox_wrapper", 'w')
+        fwp.write("#!%s" % (target))
+        os.fchmod(fwp.fileno(), mode)
+        fwp.close()
+        # Install the sh wrappers and alternatives reset to link to them
+        wpdir = os.path.join(d.getVar('libdir', True), pn)
+        wpdir_dest = '%s%s' % (dvar, wpdir)
+        if not os.path.exists(wpdir_dest):
+            os.makedirs(wpdir_dest)
+        f = open('%s%s' % (dvar, links), 'r')
+        for alt_link_name in f:
+            alt_link_name = alt_link_name.strip()
+            alt_name = os.path.basename(alt_link_name)
+            # Copy script wrapper to wp_path
+            alt_wppath = '%s%s' % (wpdir, alt_link_name)
+            alt_wppath_dest = '%s%s' % (wpdir_dest, alt_link_name) 
+            alt_wpdir_dest = os.path.dirname(alt_wppath_dest)
+            if not os.path.exists(alt_wpdir_dest):
+                os.makedirs(alt_wpdir_dest)
+            shutil.copy2("busybox_wrapper", alt_wppath_dest)
+            # Re-set alternatives
+            # Match coreutils
+            if alt_name == '[':
+                alt_name = 'lbracket'
+            d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
+            d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, alt_link_name)
+            if os.path.exists(alt_wppath_dest):
+                d.setVarFlag('ALTERNATIVE_TARGET', alt_name, alt_wppath)
+        f.close()
+
+        os.remove("busybox_wrapper")
+        return
+
+    if os.path.exists('%s/etc/busybox.links' % (dvar)):
+        create_sh_alternative_vars("/etc/busybox.links", "/bin/busybox", 0o0755)
+    else:
+        create_sh_alternative_vars("/etc/busybox.links.nosuid", "/bin/busybox.nosuid", 0o0755)
+        create_sh_alternative_vars("/etc/busybox.links.suid", "/bin/busybox.suid", 0o4755)
+}
+
+# Add to PACKAGEBUILDPKGD so it could override the alternatives, which are set in
+# do_package_prepend() section of busybox_*.bb.
+PACKAGEBUILDPKGD_prepend = "create_sh_wrapper_reset_alternative_vars "
+
+# Use sh wrappers instead of links
+pkg_postinst_${PN} () {
+	# This part of code is dedicated to the on target upgrade problem.
+	# It's known that if we don't make appropriate symlinks before update-alternatives calls,
+	# there will be errors indicating missing commands such as 'sed'.
+	# These symlinks will later be updated by update-alternatives calls.
+	test -n 2 > /dev/null || alias test='busybox test'
+	if test "x$D" = "x"; then
+		# Remove busybox.nosuid if it's a symlink, because this situation indicates
+		# that we're installing or upgrading to a one-binary busybox.
+		if test -h /bin/busybox.nosuid; then
+			rm -f /bin/busybox.nosuid
+		fi
+		for suffix in "" ".nosuid" ".suid"; do
+			if test -e /etc/busybox.links$suffix; then
+				while read link; do
+					if test ! -e "$link"; then
+						# we can use busybox here because even if we are using splitted busybox
+						# we've made a symlink from /bin/busybox to /bin/busybox.nosuid.
+						busybox echo "#!/bin/busybox$suffix" > $link
+					fi
+				done < /etc/busybox.links$suffix
+			fi
+		done
+	fi
+}
+
diff --git a/recipes-core/busybox/busybox_1.21.1.bbappend b/recipes-core/busybox/busybox_1.21.1.bbappend
deleted file mode 100644
index b4935b2..0000000
--- a/recipes-core/busybox/busybox_1.21.1.bbappend
+++ /dev/null
@@ -1,87 +0,0 @@
-PR .= ".1"
-
-FILES_${PN} += "${libdir}/${PN}"
-
-# We should use sh wrappers instead of links so the commands could get correct
-# security labels
-python create_sh_wrapper_reset_alternative_vars () {
-    # We need to load the full set of busybox provides from the /etc/busybox.links
-    # Use this to see the update-alternatives with the right information
-
-    dvar = d.getVar('D', True)
-    pn = d.getVar('PN', True)
-
-    def create_sh_alternative_vars(links, target, mode):
-        import shutil
-        # Create sh wrapper template
-        fwp = open("busybox_wrapper", 'w')
-        fwp.write("#!%s" % (target))
-        os.fchmod(fwp.fileno(), mode)
-        fwp.close()
-        # Install the sh wrappers and alternatives reset to link to them
-        wpdir = os.path.join(d.getVar('libdir', True), pn)
-        wpdir_dest = '%s%s' % (dvar, wpdir)
-        if not os.path.exists(wpdir_dest):
-            os.makedirs(wpdir_dest)
-        f = open('%s%s' % (dvar, links), 'r')
-        for alt_link_name in f:
-            alt_link_name = alt_link_name.strip()
-            alt_name = os.path.basename(alt_link_name)
-            # Copy script wrapper to wp_path
-            alt_wppath = '%s%s' % (wpdir, alt_link_name)
-            alt_wppath_dest = '%s%s' % (wpdir_dest, alt_link_name) 
-            alt_wpdir_dest = os.path.dirname(alt_wppath_dest)
-            if not os.path.exists(alt_wpdir_dest):
-                os.makedirs(alt_wpdir_dest)
-            shutil.copy2("busybox_wrapper", alt_wppath_dest)
-            # Re-set alternatives
-            # Match coreutils
-            if alt_name == '[':
-                alt_name = 'lbracket'
-            d.appendVar('ALTERNATIVE_%s' % (pn), ' ' + alt_name)
-            d.setVarFlag('ALTERNATIVE_LINK_NAME', alt_name, alt_link_name)
-            if os.path.exists(alt_wppath_dest):
-                d.setVarFlag('ALTERNATIVE_TARGET', alt_name, alt_wppath)
-        f.close()
-
-        os.remove("busybox_wrapper")
-        return
-
-    if os.path.exists('%s/etc/busybox.links' % (dvar)):
-        create_sh_alternative_vars("/etc/busybox.links", "/bin/busybox", 0o0755)
-    else:
-        create_sh_alternative_vars("/etc/busybox.links.nosuid", "/bin/busybox.nosuid", 0o0755)
-        create_sh_alternative_vars("/etc/busybox.links.suid", "/bin/busybox.suid", 0o4755)
-}
-
-# Add to PACKAGEBUILDPKGD so it could override the alternatives, which are set in
-# do_package_prepend() section of busybox_*.bb.
-PACKAGEBUILDPKGD_prepend = "create_sh_wrapper_reset_alternative_vars "
-
-# Use sh wrappers instead of links
-pkg_postinst_${PN} () {
-	# This part of code is dedicated to the on target upgrade problem.
-	# It's known that if we don't make appropriate symlinks before update-alternatives calls,
-	# there will be errors indicating missing commands such as 'sed'.
-	# These symlinks will later be updated by update-alternatives calls.
-	test -n 2 > /dev/null || alias test='busybox test'
-	if test "x$D" = "x"; then
-		# Remove busybox.nosuid if it's a symlink, because this situation indicates
-		# that we're installing or upgrading to a one-binary busybox.
-		if test -h /bin/busybox.nosuid; then
-			rm -f /bin/busybox.nosuid
-		fi
-		for suffix in "" ".nosuid" ".suid"; do
-			if test -e /etc/busybox.links$suffix; then
-				while read link; do
-					if test ! -e "$link"; then
-						# we can use busybox here because even if we are using splitted busybox
-						# we've made a symlink from /bin/busybox to /bin/busybox.nosuid.
-						busybox echo "#!/bin/busybox$suffix" > $link
-					fi
-				done < /etc/busybox.links$suffix
-			fi
-		done
-	fi
-}
-
-- 
1.7.10.4

[meta-selinux][PATCH 2/4] libcgroup: Use wildcard for version number in libcgroup bbappend.

[Philip Tricca]

Signed-off-by: Philip Tricca <flihp@twobit.us>

 create mode 100644 recipes-core/libcgroup/libcgroup_%.bbappend
 delete mode 100644 recipes-core/libcgroup/libcgroup_0.38.bbappend

diff --git a/recipes-core/libcgroup/libcgroup_%.bbappend b/recipes-core/libcgroup/libcgroup_%.bbappend
new file mode 100644
index 0000000..b7e0c5f
--- /dev/null
+++ b/recipes-core/libcgroup/libcgroup_%.bbappend
@@ -0,0 +1,12 @@
+PR .= ".3"
+
+EXTRA_OECONF_virtclass-native = "--enable-pam=no"
+
+do_install_append() {
+	test ! -f ${D}${base_libdir}/security/pam_cgroup.so.0.0.0 || {
+		mv -f ${D}${base_libdir}/security/pam_cgroup.so.0.0.0 ${D}${base_libdir}/security/pam_cgroup.so
+		rm -f ${D}${base_libdir}/security/pam_cgroup.so.*
+	}
+}
+
+BBCLASSEXTEND = "native"
diff --git a/recipes-core/libcgroup/libcgroup_0.38.bbappend b/recipes-core/libcgroup/libcgroup_0.38.bbappend
deleted file mode 100644
index b7e0c5f..0000000
--- a/recipes-core/libcgroup/libcgroup_0.38.bbappend
+++ /dev/null
@@ -1,12 +0,0 @@
-PR .= ".3"
-
-EXTRA_OECONF_virtclass-native = "--enable-pam=no"
-
-do_install_append() {
-	test ! -f ${D}${base_libdir}/security/pam_cgroup.so.0.0.0 || {
-		mv -f ${D}${base_libdir}/security/pam_cgroup.so.0.0.0 ${D}${base_libdir}/security/pam_cgroup.so
-		rm -f ${D}${base_libdir}/security/pam_cgroup.so.*
-	}
-}
-
-BBCLASSEXTEND = "native"
-- 
1.7.10.4

[meta-selinux][PATCH 3/4] sudo: Use wildcard for version number in sudo bbappend.

[Philip Tricca]

Signed-off-by: Philip Tricca <flihp@twobit.us>

 create mode 100644 recipes-extended/sudo/sudo_%.bbappend
 delete mode 100644 recipes-extended/sudo/sudo_1.8.8.bbappend

diff --git a/recipes-extended/sudo/sudo_%.bbappend b/recipes-extended/sudo/sudo_%.bbappend
new file mode 100644
index 0000000..5ad8973
--- /dev/null
+++ b/recipes-extended/sudo/sudo_%.bbappend
@@ -0,0 +1,3 @@
+PR .= ".2"
+
+inherit with-selinux
diff --git a/recipes-extended/sudo/sudo_1.8.8.bbappend b/recipes-extended/sudo/sudo_1.8.8.bbappend
deleted file mode 100644
index 5ad8973..0000000
--- a/recipes-extended/sudo/sudo_1.8.8.bbappend
+++ /dev/null
@@ -1,3 +0,0 @@
-PR .= ".2"
-
-inherit with-selinux
-- 
1.7.10.4

[meta-selinux][PATCH 4/4] libxcb: Use wildcard for version number in libxcb bbappend.

[Philip Tricca]

Signed-off-by: Philip Tricca <flihp@twobit.us>

 create mode 100644 recipes-graphics/xcb/libxcb_%.bbappend
 delete mode 100644 recipes-graphics/xcb/libxcb_1.9.3.bbappend

diff --git a/recipes-graphics/xcb/libxcb_%.bbappend b/recipes-graphics/xcb/libxcb_%.bbappend
new file mode 100644
index 0000000..f1bd5a8
--- /dev/null
+++ b/recipes-graphics/xcb/libxcb_%.bbappend
@@ -0,0 +1,8 @@
+PR .= ".1"
+
+inherit enable-selinux
+# libxcb-xselinux will not build with libselinux, so remove the depend
+PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,,"
+
+PACKAGES += "${PN}-xselinux"
+FILES_${PN}-xselinux += "${libdir}/libxcb-xselinux.so.*"
diff --git a/recipes-graphics/xcb/libxcb_1.9.3.bbappend b/recipes-graphics/xcb/libxcb_1.9.3.bbappend
deleted file mode 100644
index f1bd5a8..0000000
--- a/recipes-graphics/xcb/libxcb_1.9.3.bbappend
+++ /dev/null
@@ -1,8 +0,0 @@
-PR .= ".1"
-
-inherit enable-selinux
-# libxcb-xselinux will not build with libselinux, so remove the depend
-PACKAGECONFIG[selinux] = "--enable-selinux,--disable-selinux,,"
-
-PACKAGES += "${PN}-xselinux"
-FILES_${PN}-xselinux += "${libdir}/libxcb-xselinux.so.*"
-- 
1.7.10.4

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

[Randy MacLeod]

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

Hi Philip,

This might work out but I'm somewhat attached to the manual process.
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
>


-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 3907 bytes --]

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

-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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Philip Tricca]

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

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

[Randy MacLeod]

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.

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


-- 
# Randy MacLeod. SMTS, Linux, Wind River
Direct: 613.963.1350

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 5613 bytes --]

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

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

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

[Pascal Ouyang]

于 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

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

[Joe MacDonald]

[-- Attachment #1: Type: text/plain, Size: 7114 bytes --]

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@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
> 
> 
-- 
-Joe MacDonald.
:wq

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]