Re: [PATCH 1/1] image.bbclass: leave metadata in place if a PM is installed in the image

[ChenQi <Qi.Chen@windriver.com>]

On 09/05/2013 07:11 PM, Laurentiu Palcu wrote:
> On Thu, Sep 05, 2013 at 11:43:54AM +0100, Phil Blundell wrote:
>> On Thu, 2013-09-05 at 10:15 +0200, Martin Jansa wrote:
>>> On Thu, Sep 05, 2013 at 10:31:10AM +0300, Laurentiu Palcu wrote:
>>>>   rootfs_uninstall_unneeded () {
>>>> -	if ${@base_contains("IMAGE_FEATURES", "package-management", "false", "true", d)}; then
>>>> +	rpm_installed=${@base_contains("PACKAGE_INSTALL", "rpm",  "true", "false", d)}
>>>> +	opkg_installed=${@base_contains("PACKAGE_INSTALL", "opkg", "true", "false", d)}
>>>> +	dpkg_installed=${@base_contains("PACKAGE_INSTALL", "dpkg", "true", "false", d)}
>>>> +
>>>> +	if ${@base_contains("IMAGE_FEATURES", "package-management", "false", "true", d)} &&\
>>> is this first condition still needed? Do we have some case where
>>> package-management is enabled without rpm/opkg/dpkg installed?
>> Yes, potentially.  It is quite legitimate to have package-management in
>> IMAGE_FEATURES (in order to have the metadata kept around for later
>> inspection) but not actually install any of the package managers.  In
>> fact, this is basically all that the package-management feature does,
>> and revoking support for it in favour of needing to specify something in
>> PACKAGE_INSTALL seems like it would be a retrograde step.
> This patch does not revoke support for 'package-management' in
> IMAGE_FEATURES. It just makes sure not to remove anything if a PM is
> present in the image. Those packages will be, potentially, needed by
> postinstalls etc.
>> Replacing the generic IMAGE_FEATURES test with something based on the
>> presence of one of three specific package managers also has a few other
>> minor downsides:
>>
>> - it makes it harder for someone to maintain support for a different
>> package manager outside of oe-core;
> I agree here.
>
>> - it means that mentioning rpm in PACKAGE_INSTALL for an opkg-based
>> image will still cause all the opkg metadata to be retained, which might
>> be surprising to some;
> Also true, but we cannot really deal with all combinations... can we?
>
>> - it makes it impossible to install opkg or suchlike without its
>> metadata, which has occasionally been a useful thing to do.
> Is this a valid use case? Besides, right now, if you don't have
> 'package-management' in IMAGE_FEATURES but have opkg installed you will,
> indeed, have opkg installed without metadata but also update-rc.d,
> base-passwd and run-postinsts will be removed from the image. This means
> that opkg will be slightly useless since postinstalls might need
> update-rc.d to complete. Or, if there are delayed postinstalls,
> run-postinsts package has to be present too, in order to have those run
> at first boot.
>
>> I don't think any of the above are necessarily deal-breakers, but it
>> does seem to me that this patch is based on an erroneous premise.  If
>> the user wants package management then they should simply be adding that
>> flag to IMAGE_FEATURES.  I don't think it's necessary or desirable that
>> image.bbclass try to second-guess this by looking at the list of
>> packages to be installed and applying some heuristic.
> This solution is the most decent I could find in order to address this:
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=4484
> in this stage of 1.5 release. Other ideas are always welcome.

Hi Laurentiu,

I don't think run-postinst should rely on the presence of a PM.
Whether to delete the run-postinst should only be determined by whether 
there are some delayed postinst scripts.

So I think the logic in this remove function should be divided into two 
parts.
Part 1, remove package management related data if 'package-management' 
is not in IMAGE_FEATURES.
Part 2, remove the run-postinst if there's no delayed postisnt script.

Besides, I think that update-rc.d should not be removed, because it's 
actually useful to manage things in a system with a runlevel concept.

Best Regards,
Chen Qi

> Thanks,
> Laurentiu
>
>> p.
>>
>>
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>