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
_______________________________________________
Openembedded-core mailing list
Openembedded-core@lists.openembedded.org
http://lists.openembedded.org/mailman/listinfo/openembedded-core
