Patchwork [03/11] package_rpm.bbclass: Add support for PACKAGE_EXCLUDE to RPM installs

login
register
mail settings
Submitter Mark Hatle
Date Aug. 14, 2013, 8:30 p.m.
Message ID <1376512209-11622-4-git-send-email-mark.hatle@windriver.com>
Download mbox | patch
Permalink /patch/55627/
State Accepted
Commit 238c46c03d0d9c35523c78b94bfebb57904bac5a
Headers show

Comments

Mark Hatle - Aug. 14, 2013, 8:30 p.m.
Using the new smart exclude mechanism an error will be generated in the
excluded package is required for the image to be generated.

Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
---
 meta/classes/package_rpm.bbclass | 5 +++++
 1 file changed, 5 insertions(+)
Paul Eggleton - Aug. 15, 2013, 12:01 p.m.
On Wednesday 14 August 2013 15:30:01 Mark Hatle wrote:
> Using the new smart exclude mechanism an error will be generated in the
> excluded package is required for the image to be generated.
> 
> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
> ---
>  meta/classes/package_rpm.bbclass | 5 +++++
>  1 file changed, 5 insertions(+)
> 
> diff --git a/meta/classes/package_rpm.bbclass
> b/meta/classes/package_rpm.bbclass index 324d83f..74ae0ed 100644
> --- a/meta/classes/package_rpm.bbclass
> +++ b/meta/classes/package_rpm.bbclass
> @@ -356,6 +356,11 @@ EOF
>  		smart --data-dir=${target_rootfs}/var/lib/smart config --set
> rpm-extra-macros._var=${localstatedir} smart
> --data-dir=${target_rootfs}/var/lib/smart config --set
> rpm-extra-macros._tmppath=/install/tmp package_write_smart_config
> ${target_rootfs}
> +		# Do the following configurations here, to avoid them being saved for
> field upgrade 
> +		for i in ${PACKAGE_EXCLUDE}; do
> +			smart --data-dir=$1/var/lib/smart flag --set exclude-packages $i
> +		done

IMO, it would be correct to persist these exclusions into the runtime 
configuration. Not doing so is inconsistent with the behaviour of 
BAD_RECOMMENDATIONS, and it means that if you do an upgrade or an install on 
the target, these excluded packages can sneak back in which I would think 
would not be desirable unless the user explicitly turns off the exclusion. 
Clearing the flag if it were persisted is easy to do with smart.

Cheers,
Paul
Mark Hatle - Aug. 15, 2013, 1:37 p.m.
On 8/15/13 7:01 AM, Paul Eggleton wrote:
> On Wednesday 14 August 2013 15:30:01 Mark Hatle wrote:
>> Using the new smart exclude mechanism an error will be generated in the
>> excluded package is required for the image to be generated.
>>
>> Signed-off-by: Mark Hatle <mark.hatle@windriver.com>
>> ---
>>   meta/classes/package_rpm.bbclass | 5 +++++
>>   1 file changed, 5 insertions(+)
>>
>> diff --git a/meta/classes/package_rpm.bbclass
>> b/meta/classes/package_rpm.bbclass index 324d83f..74ae0ed 100644
>> --- a/meta/classes/package_rpm.bbclass
>> +++ b/meta/classes/package_rpm.bbclass
>> @@ -356,6 +356,11 @@ EOF
>>   		smart --data-dir=${target_rootfs}/var/lib/smart config --set
>> rpm-extra-macros._var=${localstatedir} smart
>> --data-dir=${target_rootfs}/var/lib/smart config --set
>> rpm-extra-macros._tmppath=/install/tmp package_write_smart_config
>> ${target_rootfs}
>> +		# Do the following configurations here, to avoid them being saved for
>> field upgrade
>> +		for i in ${PACKAGE_EXCLUDE}; do
>> +			smart --data-dir=$1/var/lib/smart flag --set exclude-packages $i
>> +		done
>
> IMO, it would be correct to persist these exclusions into the runtime
> configuration. Not doing so is inconsistent with the behaviour of
> BAD_RECOMMENDATIONS, and it means that if you do an upgrade or an install on
> the target, these excluded packages can sneak back in which I would think
> would not be desirable unless the user explicitly turns off the exclusion.
> Clearing the flag if it were persisted is easy to do with smart.

(I spoke w/ Paul on IRC about this briefly yesterday.. so this is more a recap 
for the mailing list.)

The deb and ipk implementation of the exclude packages makes them transient.  If 
we want consistent behavior, we'll likely need to change the deb/apt-get pin 
file to make them persistent... and for ipk, I'm not exactly sure how to do 
this.  We're not saving the list of excluded files anywhere.

If a difference in behavior between the packaging systems is acceptable, then 
moving the rpm(smart) exclude code should be fairly easy to make persistent.

HOWEVER, I'm not sure we really want it to be persistent.  Just because the 
initial image generation may have skipped specific files, doesn't necessarily 
mean they should be skipped on the target (field/user upgrade scenario).  If we 
do persist them, we need to somehow make it clear to the end user how to clear 
the setting(s) as well, and that isn't always very obvious.

Both positions may be negated by the fact these are embedded systems, and in 
many cases simply don't end up with a package database on the target.  So it 
doesn't really matter in those cases.  It's more the specialized case where 
field upgrade / additional field software install could happen.

Does anyone else have opinions on this?  I can certainly see reasons for both, 
but I'm not sure if one is more appropriate then the other at this point.

--Mark

> Cheers,
> Paul
>

Patch

diff --git a/meta/classes/package_rpm.bbclass b/meta/classes/package_rpm.bbclass
index 324d83f..74ae0ed 100644
--- a/meta/classes/package_rpm.bbclass
+++ b/meta/classes/package_rpm.bbclass
@@ -356,6 +356,11 @@  EOF
 		smart --data-dir=${target_rootfs}/var/lib/smart config --set rpm-extra-macros._var=${localstatedir}
 		smart --data-dir=${target_rootfs}/var/lib/smart config --set rpm-extra-macros._tmppath=/install/tmp
 		package_write_smart_config ${target_rootfs}
+		# Do the following configurations here, to avoid them being saved for field upgrade
+		for i in ${PACKAGE_EXCLUDE}; do
+			smart --data-dir=$1/var/lib/smart flag --set exclude-packages $i
+		done
+
 		# Optional debugging
 		#smart --data-dir=${target_rootfs}/var/lib/smart config --set rpm-log-level=debug
 		#smart --data-dir=${target_rootfs}/var/lib/smart config --set rpm-log-file=/tmp/smart-debug-logfile