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

[Laurentiu Palcu]

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.

Thanks,
Laurentiu

> 
> p.
> 
>