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

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

[Laurentiu Palcu]

The following changes since commit f41b7a7d4d0463a0dfafe6621d01680b81798019:

  bitbake: hob: remove PACKAGE_INSTALL variable setting from hob (2013-09-04 14:18:49 +0100)

are available in the git repository at:

  git://git.yoctoproject.org/poky-contrib lpalcu/b4484_postinstalls_dont_run_for_ipk
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=lpalcu/b4484_postinstalls_dont_run_for_ipk

Laurentiu Palcu (1):
  image.bbclass: leave metadata in place if a PM is installed in the
    image

 meta/classes/image.bbclass |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
1.7.9.5

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

[Laurentiu Palcu]

If IMAGE_FEATURES does not contain 'package-management' but the user
manually installs a package manager (opkg/dpkg/rpm) using
CORE_IMAGE_EXTRA_INSTALL (for example), then do not remove update-rc.d,
base-passwd and package metadata because these will be needed by the
package manager to function correcly.

[YOCTO #4484]

Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
---
 meta/classes/image.bbclass |    7 ++++++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 84f638c..e1a7367 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -498,7 +498,12 @@ rootfs_install_complementary() {
 }
 
 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)} &&\
+	   ! $rpm_installed && ! $opkg_installed && ! $dpkg_installed; then
 		if [ -z "$(delayed_postinsts)" ]; then
 			# All packages were successfully configured.
 			# update-rc.d, base-passwd, run-postinsts are no further use, remove them now
-- 
1.7.9.5

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

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 1974 bytes --]

On Thu, Sep 05, 2013 at 10:31:10AM +0300, Laurentiu Palcu wrote:
> If IMAGE_FEATURES does not contain 'package-management' but the user
> manually installs a package manager (opkg/dpkg/rpm) using
> CORE_IMAGE_EXTRA_INSTALL (for example), then do not remove update-rc.d,
> base-passwd and package metadata because these will be needed by the
> package manager to function correcly.
> 
> [YOCTO #4484]
> 
> Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> ---
>  meta/classes/image.bbclass |    7 ++++++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> index 84f638c..e1a7367 100644
> --- a/meta/classes/image.bbclass
> +++ b/meta/classes/image.bbclass
> @@ -498,7 +498,12 @@ rootfs_install_complementary() {
>  }
>  
>  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?

> +	   ! $rpm_installed && ! $opkg_installed && ! $dpkg_installed; then
>  		if [ -z "$(delayed_postinsts)" ]; then
>  			# All packages were successfully configured.
>  			# update-rc.d, base-passwd, run-postinsts are no further use, remove them now
> -- 
> 1.7.9.5
> 
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 205 bytes --]

Re: [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 10:15:16AM +0200, Martin Jansa wrote:
> On Thu, Sep 05, 2013 at 10:31:10AM +0300, Laurentiu Palcu wrote:
> > If IMAGE_FEATURES does not contain 'package-management' but the user
> > manually installs a package manager (opkg/dpkg/rpm) using
> > CORE_IMAGE_EXTRA_INSTALL (for example), then do not remove update-rc.d,
> > base-passwd and package metadata because these will be needed by the
> > package manager to function correcly.
> > 
> > [YOCTO #4484]
> > 
> > Signed-off-by: Laurentiu Palcu <laurentiu.palcu@intel.com>
> > ---
> >  meta/classes/image.bbclass |    7 ++++++-
> >  1 file changed, 6 insertions(+), 1 deletion(-)
> > 
> > diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
> > index 84f638c..e1a7367 100644
> > --- a/meta/classes/image.bbclass
> > +++ b/meta/classes/image.bbclass
> > @@ -498,7 +498,12 @@ rootfs_install_complementary() {
> >  }
> >  
> >  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?
I believe you're right. That condition can be removed.

Thanks,
Laurentiu
> 
> > +	   ! $rpm_installed && ! $opkg_installed && ! $dpkg_installed; then
> >  		if [ -z "$(delayed_postinsts)" ]; then
> >  			# All packages were successfully configured.
> >  			# update-rc.d, base-passwd, run-postinsts are no further use, remove them now
> > -- 
> > 1.7.9.5
> > 
> > _______________________________________________
> > Openembedded-core mailing list
> > Openembedded-core@lists.openembedded.org
> > http://lists.openembedded.org/mailman/listinfo/openembedded-core
> 
> -- 
> Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

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

[Phil Blundell]

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. 

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;

- 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;

- it makes it impossible to install opkg or suchlike without its
metadata, which has occasionally been a useful thing to do.

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.

p.

Re: [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.
> 
> 

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

[Phil Blundell]

On Thu, 2013-09-05 at 14:11 +0300, Laurentiu Palcu wrote:
> 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.

I couldn't quite follow the long and complicated history of that bug,
but based on the description and the contents of comment #1 it sounds as
though the bug is at best tangentially related to this issue.

In the case where you have postinsts on the target but package
management is disabled, rootfs_ipk should be installing run-postinsts
(not opkg) and in that case it doesn't seem like this patch will help.

It looks as though this breakage was probably introduced by
928df79cd3964f775c4c6e4283ef84b8882f9328 which moved the call to
remove_packaging_data_files() from rootfs_ipk (which was only calling it
if it knew that all postinsts had already been completed) to
image.bbclass (which doesn't have that knowledge and will call it
irrespective of what state the postinsts are in).

p.

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

[Phil Blundell]

On Thu, 2013-09-05 at 12:37 +0100, Phil Blundell wrote:
> On Thu, 2013-09-05 at 14:11 +0300, Laurentiu Palcu wrote:
> > 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.
> 
> I couldn't quite follow the long and complicated history of that bug,
> but based on the description and the contents of comment #1 it sounds as
> though the bug is at best tangentially related to this issue.
> 
> In the case where you have postinsts on the target but package
> management is disabled, rootfs_ipk should be installing run-postinsts
> (not opkg) and in that case it doesn't seem like this patch will help.
> 
> It looks as though this breakage was probably introduced by
> 928df79cd3964f775c4c6e4283ef84b8882f9328 which moved the call to
> remove_packaging_data_files() from rootfs_ipk (which was only calling it
> if it knew that all postinsts had already been completed) to
> image.bbclass (which doesn't have that knowledge and will call it
> irrespective of what state the postinsts are in).

Actually, that last sentence is slightly incorrect.  image.bbclass does
have the knowledge, it just seems to be failing to act on it.  So
perhaps the easiest fix for the time being is simply to move the
remove_packaging_data_files call in rootfs_uninstall_unneeded () a few
lines higher up so that it's inside the "if [ -z $(delayed_postinsts) ]"
block.

p.

Re: [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 12:40:26PM +0100, Phil Blundell wrote:
> On Thu, 2013-09-05 at 12:37 +0100, Phil Blundell wrote:
> > On Thu, 2013-09-05 at 14:11 +0300, Laurentiu Palcu wrote:
> > > 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.
> > 
> > I couldn't quite follow the long and complicated history of that bug,
> > but based on the description and the contents of comment #1 it sounds as
> > though the bug is at best tangentially related to this issue.
See last comment to understand what this patch fixes. The original issue
was fixed by the patchset mentioned here:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4484#c4
> > 
> > In the case where you have postinsts on the target but package
> > management is disabled, rootfs_ipk should be installing run-postinsts
> > (not opkg) and in that case it doesn't seem like this patch will help.
> > 
> > It looks as though this breakage was probably introduced by
> > 928df79cd3964f775c4c6e4283ef84b8882f9328 which moved the call to
> > remove_packaging_data_files() from rootfs_ipk (which was only calling it
> > if it knew that all postinsts had already been completed) to
> > image.bbclass (which doesn't have that knowledge and will call it
> > irrespective of what state the postinsts are in).
> 
> Actually, that last sentence is slightly incorrect.  image.bbclass does
> have the knowledge, it just seems to be failing to act on it.  So
> perhaps the easiest fix for the time being is simply to move the
> remove_packaging_data_files call in rootfs_uninstall_unneeded () a few
> lines higher up so that it's inside the "if [ -z $(delayed_postinsts) ]"
> block.
What you're suggesting means that we will have the PM metadata present
if there are delayed postinstalls present. But, since the PM is not
present, what's the use of that? Your suggestion will work, however, in
the case Paul mentioned, when reopening the bug, but we'll break the
current functionality...

Thanks,
Laurentiu
> 
> p.
> 
> 

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

[Phil Blundell]

On Thu, 2013-09-05 at 06:59 -0500, Laurentiu Palcu wrote:
> On Thu, Sep 05, 2013 at 12:40:26PM +0100, Phil Blundell wrote:
> > Actually, that last sentence is slightly incorrect.  image.bbclass does
> > have the knowledge, it just seems to be failing to act on it.  So
> > perhaps the easiest fix for the time being is simply to move the
> > remove_packaging_data_files call in rootfs_uninstall_unneeded () a few
> > lines higher up so that it's inside the "if [ -z $(delayed_postinsts) ]"
> > block.
> What you're suggesting means that we will have the PM metadata present
> if there are delayed postinstalls present. But, since the PM is not
> present, what's the use of that? 

Well, er, that it will make the postinstalls work.  Isn't that exactly
the problem here?

p.

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

[Paul Eggleton]

On Thursday 05 September 2013 13:07:20 Phil Blundell wrote:
> On Thu, 2013-09-05 at 06:59 -0500, Laurentiu Palcu wrote:
> > On Thu, Sep 05, 2013 at 12:40:26PM +0100, Phil Blundell wrote:
> > > Actually, that last sentence is slightly incorrect.  image.bbclass does
> > > have the knowledge, it just seems to be failing to act on it.  So
> > > perhaps the easiest fix for the time being is simply to move the
> > > remove_packaging_data_files call in rootfs_uninstall_unneeded () a few
> > > lines higher up so that it's inside the "if [ -z $(delayed_postinsts) ]"
> > > block.
> > 
> > What you're suggesting means that we will have the PM metadata present
> > if there are delayed postinstalls present. But, since the PM is not
> > present, what's the use of that?
> 
> Well, er, that it will make the postinstalls work.  Isn't that exactly
> the problem here?

I'm clearly missing something here. If we have a generic mechanism to run 
postinstall scripts now, and "package-management" is not in IMAGE_FEATURES, 
why do we need or want the package manager to be in control of running the 
postinstalls?

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

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

[Phil Blundell]

On Thu, 2013-09-05 at 07:19 -0500, Paul Eggleton wrote:
> I'm clearly missing something here. If we have a generic mechanism to run 
> postinstall scripts now, and "package-management" is not in IMAGE_FEATURES, 
> why do we need or want the package manager to be in control of running the 
> postinstalls?

We don't.  The postinsts should be getting run by run-postinsts.

I must admit I still don't entirely understand what the problem is that
Laurentiu is trying to fix with his patch, and the description in the
Yocto bugzilla remains opaque to me.  Can you clarify what exactly it is
that's currently going wrong?

p.

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

[Paul Eggleton]

On Thursday 05 September 2013 13:29:34 Phil Blundell wrote:
> On Thu, 2013-09-05 at 07:19 -0500, Paul Eggleton wrote:
> > I'm clearly missing something here. If we have a generic mechanism to run
> > postinstall scripts now, and "package-management" is not in
> > IMAGE_FEATURES,
> > why do we need or want the package manager to be in control of running the
> > postinstalls?
> 
> We don't.  The postinsts should be getting run by run-postinsts.
> 
> I must admit I still don't entirely understand what the problem is that
> Laurentiu is trying to fix with his patch, and the description in the
> Yocto bugzilla remains opaque to me.  Can you clarify what exactly it is
> that's currently going wrong?

The reason I reopened the bug (the final comment) is that I had a situation 
recently where I had got opkg installed in an image via dependencies and I did 
not have package-management in IMAGE_FEATURES. The result was that 
postinstalls to be run on first boot just silently did not work, which is not 
good behaviour.

Now, with the image I was dealing with I needed to add package-management to 
IMAGE_FEATURES anyway; but things shouldn't just silently break because the 
package manager happens to be installed especially as it may not be 
immediately clear to the user that the latter had even happened. I'm pretty 
sure this didn't used to be an issue.

Cheers,
Paul

-- 

Paul Eggleton
Intel Open Source Technology Centre

Re: [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 01:53:44PM +0100, Paul Eggleton wrote:
> On Thursday 05 September 2013 13:29:34 Phil Blundell wrote:
> > On Thu, 2013-09-05 at 07:19 -0500, Paul Eggleton wrote:
> > > I'm clearly missing something here. If we have a generic mechanism to run
> > > postinstall scripts now, and "package-management" is not in
> > > IMAGE_FEATURES,
> > > why do we need or want the package manager to be in control of running the
> > > postinstalls?
> > 
> > We don't.  The postinsts should be getting run by run-postinsts.
> > 
> > I must admit I still don't entirely understand what the problem is that
> > Laurentiu is trying to fix with his patch, and the description in the
> > Yocto bugzilla remains opaque to me.  Can you clarify what exactly it is
> > that's currently going wrong?
> 
> The reason I reopened the bug (the final comment) is that I had a situation 
> recently where I had got opkg installed in an image via dependencies and I did 
> not have package-management in IMAGE_FEATURES. The result was that 
> postinstalls to be run on first boot just silently did not work, which is not 
> good behaviour.
> 
> Now, with the image I was dealing with I needed to add package-management to 
> IMAGE_FEATURES anyway; but things shouldn't just silently break because the 
> package manager happens to be installed especially as it may not be 
> immediately clear to the user that the latter had even happened. I'm pretty 
> sure this didn't used to be an issue.
Well, it's present since denzil anyway. You confirmed it yourself Paul:
https://bugzilla.yoctoproject.org/show_bug.cgi?id=4484#c13

Before the rework, the metadata (for opkg at least) was deleted no
matter what during rootfs generation. So, there's no way this case (no
'package-management' in IMAGE_FEATURES and opkg installed) worked
recently.

Anyway, do we have a better idea? The solution Phil suggested, is not
quite ok... We'll end up with useless metadata if no PM is installed and
delayed postinstalls are present or, the other case, have the PM
installed with no metadata if the PM is installed but we have no delayed
postinstalls...

Thanks,
Laurentiu

> 
> Cheers,
> Paul
> 
> -- 
> 
> Paul Eggleton
> Intel Open Source Technology Centre

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

[Phil Blundell]

On Thu, 2013-09-05 at 16:14 +0300, Laurentiu Palcu wrote:
> Before the rework, the metadata (for opkg at least) was deleted no
> matter what during rootfs generation. So, there's no way this case (no
> 'package-management' in IMAGE_FEATURES and opkg installed) worked
> recently.
> 
> Anyway, do we have a better idea? The solution Phil suggested, is not
> quite ok... We'll end up with useless metadata if no PM is installed and
> delayed postinstalls are present or, the other case, have the PM
> installed with no metadata if the PM is installed but we have no delayed
> postinstalls...

What is it that actually causes run-postinsts to fail when opkg is
installed?  I guess that's the bit that I'm not understanding at the
moment.  As far as I can tell from a quick inspection of run-postinsts
itself, it ought to be unperturbed by opkg's presence and no harm ought
to result.

p.

Re: [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 01:29:34PM +0100, Phil Blundell wrote:
> On Thu, 2013-09-05 at 07:19 -0500, Paul Eggleton wrote:
> > I'm clearly missing something here. If we have a generic mechanism to run 
> > postinstall scripts now, and "package-management" is not in IMAGE_FEATURES, 
> > why do we need or want the package manager to be in control of running the 
> > postinstalls?
> 
> We don't.  The postinsts should be getting run by run-postinsts.
Ok, I guess I forgot to mention why the issue mentioned by Paul happens
and run-postinsts doesn't do its job.

Well, as it happens, opkg postinstall creates a S98run-postinsts script
in rcS.d that will overwrite run-postinsts one.

We could fix that by making opkg create the script on position 97 and
both scripts will run in this case. Opkg one will fail, since there is
no metadata available, but run-postinsts will work because the
postinstalls are saved in /etc/(ipk|deb|rpm)_postinsts directory.

The only 'issue' remaining is the lack of metadata if one chooses to
manually install a PM when 'package-management' is disabled.

Now that I think about it, this might be a better alternative. But I
didn't test it though. It just came to my mind...

What do you think?

Laurentiu

> 
> I must admit I still don't entirely understand what the problem is that
> Laurentiu is trying to fix with his patch, and the description in the
> Yocto bugzilla remains opaque to me.  Can you clarify what exactly it is
> that's currently going wrong?
> 
> p.
> 
> 

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

[ChenQi]

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
>
>