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

[Mark Hatle <mark.hatle@windriver.com>]

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
>