Skip to contentSkip to conversation

Remove redundant dependencies upon opkg and opkg-collateral.

PATCH In review Graham Gower 3 participants 7 messages Aug 5, 2010 – Aug 7, 2010

lore
Share & tools
lore
#0 lore raw

PATCH 1/1 Remove redundant dependencies upon opkg and opkg-collateral.

rootfs_ipk.bbclass already pulls these in, so avoid some confusion.

This is totally untested.

---
 recipes/images/base-image.bb        |    5 -----
 recipes/images/minimal-gpe-image.bb |    1 -
 recipes/images/nas-server-image.bb  |    3 ---
 recipes/images/x11-sato-image.bb    |    2 --
 recipes/tasks/task-slugos.bb        |    1 -
 5 files changed, 0 insertions(+), 12 deletions(-)
recipes/images/base-image.bb +0 -5
index ee1f115..51d6d34 100644
@@ -20,9 +20,6 @@ IMAGE_PREPROCESS_COMMAND = "create_etc_timestamp"
 
 DISTRO_SSH_DAEMON ?= "dropbear"
 
-IPKG_VARIANT ?= "opkg"
-DISTRO_PACKAGE_MANAGER ?= "${IPKG_VARIANT}"
-
 # FIXME: We need a distro-indendent way of specifying feed configs.
 # Once the RFC for the DISTRO_FEED_CONFIGS variable name is approved,
 # we can remove this default definition and set it in the distro config.
@@ -31,7 +28,6 @@ DISTRO_FEED_CONFIGS ?= "${ANGSTROM_FEED_CONFIGS}"
 DEPENDS = "\
 	task-boot \
 	${DISTRO_SSH_DAEMON} \
-	${DISTRO_PACKAGE_MANAGER} \
 	${DISTRO_FEED_CONFIGS} \
 	${@base_contains('MACHINE_FEATURES', 'ext2', 'task-base-ext2', '', d)} \
 	${@base_contains('MACHINE_FEATURES', 'usbhost', 'task-base-usbhost', '', d)} \
@@ -40,7 +36,6 @@ DEPENDS = "\
 IMAGE_INSTALL = "\
 	task-boot \
 	${DISTRO_SSH_DAEMON} \
-	${DISTRO_PACKAGE_MANAGER} \
 	${DISTRO_FEED_CONFIGS} \
 	${@base_contains('MACHINE_FEATURES', 'ext2', 'task-base-ext2', '', d)} \
 	${@base_contains('MACHINE_FEATURES', 'usbhost', 'task-base-usbhost', '', d)} \
recipes/images/minimal-gpe-image.bb +0 -1
index 0c5c863..b8ddacb 100644
@@ -17,7 +17,6 @@ IMAGE_INSTALL = "\
     matchbox-wm \
     gpe-terminal \
     angstrom-feed-configs \
-    opkg opkg-collateral \
     ${SPLASH} \
     "
 
recipes/images/nas-server-image.bb +0 -3
index 61e8296..f26a357 100644
@@ -20,14 +20,12 @@
 # intended to be distro-agnostic.
 
 DISTRO_SSH_DAEMON ?= "dropbear"
-DISTRO_PACKAGE_MANAGER ?= "opkg opkg-collateral"
 
 DEPENDS = "\
 	task-boot \
 	${@base_contains('MACHINE_FEATURES', 'apex', 'task-base-apex', '', d)} \
 	task-distro-base task-machine-base \
 	${DISTRO_SSH_DAEMON} \
-	${DISTRO_PACKAGE_MANAGER} \
 	${@base_contains('MACHINE_FEATURES', 'ext2', 'task-base-ext2', '', d)} \
 	${@base_contains('MACHINE_FEATURES', 'usbhost', 'task-base-usbhost', '', d)} \
 	task-nas-server-everything \
@@ -41,7 +39,6 @@ IMAGE_INSTALL = "\
 	task-boot \
 	${@base_contains('MACHINE_FEATURES', 'apex', 'task-base-apex', '', d)} \
 	${DISTRO_SSH_DAEMON} \
-	${DISTRO_PACKAGE_MANAGER} \
 	${@base_contains('MACHINE_FEATURES', 'ext2', 'task-base-ext2', '', d)} \
 	${@base_contains('MACHINE_FEATURES', 'usbhost', 'task-base-usbhost', '', d)} \
 	${IMAGE_INSTALL_TASKS} \
recipes/images/x11-sato-image.bb +0 -2
index c2ed50e..f79beae 100644
@@ -1,5 +1,4 @@
 DISTRO_SSH_DAEMON ?= "dropbear"
-DISTRO_PACKAGE_MANAGER ?= "opkg opkg-collateral"
 
 XSERVER ?= "xserver-kdrive-fbdev"
 
@@ -8,7 +7,6 @@ IMAGE_PREPROCESS_COMMAND = "create_etc_timestamp"
 IMAGE_INSTALL = "\
 	task-base-extended \
 	${DISTRO_SSH_DAEMON} \
-	${DISTRO_PACKAGE_MANAGER} \
 	pointercal \
 	matchbox-wm \
 	matchbox-keyboard matchbox-keyboard-applet matchbox-keyboard-im \
recipes/tasks/task-slugos.bb +0 -1
index c007779..297d6f0 100644
@@ -133,7 +133,6 @@ RDEPENDS_${PN} += "\
         busybox initscripts-slugos slugos-init \
         update-modules sysvinit udev \
 	module-init-tools modutils-initscripts \
-        opkg-collateral ${IPKG_VARIANT} \
 	libgcc \
 	beep \
 	util-linux-mount \
Signature · 1 line
1.7.1
Acked-by on v1 1/1
#1 lore raw
Quoted 6 lines · Graham Gower

rootfs_ipk.bbclass already pulls these in, so avoid some confusion.

This is totally untested.

Looks reasonable to me.

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#2 lore raw
Quoted 4 lines · Chris Larson
Quoted 2 lines · Graham Gower

rootfs_ipk.bbclass already pulls these in, so avoid some confusion.

Quoted 8 lines
Quoted 4 lines

This is totally untested.

Looks reasonable to me.

I've already pushed it, but too late I noticed that only rootfs_ipk is handling DISTRO_PACKAGE_MANAGER and rpm/deb based rootfs will probably loose DISTRO_PACKAGE_MANAGER from image.

Should I revert now or can we fix it soon?

#3 lore raw
Quoted 12 lines · Martin Jansa
Quoted 11 lines · Chris Larson
Quoted 6 lines · Graham Gower

rootfs_ipk.bbclass already pulls these in, so avoid some confusion.

This is totally untested.

Looks reasonable to me.

Quoted 8 lines
Quoted 1 line

I've already pushed it, but too late I noticed that only rootfs_ipk is handling DISTRO_PACKAGE_MANAGER and rpm/deb based rootfs will probably loose DISTRO_PACKAGE_MANAGER from image.

Should I revert now or can we fix it soon?

DISTRO_PACKAGE_MANAGER has been removed altogether. I can't see how it would work reliably for all images - which is probably why it had multiple definitions in the first place. And you could still end up with opkg in your image when setting it to something else, e.g. minimal-gpe-image and slugos pulled opkg in unconditionally. DISTRO_PACKAGE_MANAGER could be fixed if it was put in a common location like image.bbclass.

What is the intended mechanism for selecting a package manager? INHERIT = "package_foo" looks like its going to do the trick for ipk and deb. package_rpm.bbclass might need BOOTSTRAP_EXTRA_RDEPENDS += "rpm" or something.

-Graham

#4 lore raw

PS: looks like I missed a couple of locations where opkg is pulled in unconditionally with DISTRO_EXTRA_RDEPENDS conf/distro/kaeilos.conf conf/distro/include/angstrom-2007-for-openmoko.inc

#5 lore raw
In reply to Graham Gower
Quoted 32 lines · Graham Gower
Quoted 1 line · Martin Jansa

On Thu, Aug 5, 2010 at 4:15 PM, Chris Larson <[email protected]>

Quoted 12 lines · wrote:
Quoted 1 line

On Wed, Aug 4, 2010 at 11:58 PM, Graham Gower <[email protected]

Quoted 10 lines · wrote:
Quoted 7 lines

rootfs_ipk.bbclass already pulls these in, so avoid some confusion.

This is totally untested.

Looks reasonable to me.

Quoted 8 lines
Quoted 1 line

I've already pushed it, but too late I noticed that only rootfs_ipk is handling DISTRO_PACKAGE_MANAGER and rpm/deb based rootfs will probably loose DISTRO_PACKAGE_MANAGER from image.

Should I revert now or can we fix it soon?

DISTRO_PACKAGE_MANAGER has been removed altogether. I can't see how it would work reliably for all images - which is probably why it had multiple definitions in the first place. And you could still end up with opkg in your image when setting it to something else, e.g. minimal-gpe-image and slugos pulled opkg in unconditionally. DISTRO_PACKAGE_MANAGER could be fixed if it was put in a common location like image.bbclass.

Quoted 5 lines

What is the intended mechanism for selecting a package manager? INHERIT = "package_foo" looks like its going to do the trick for ipk and deb. package_rpm.bbclass might need BOOTSTRAP_EXTRA_RDEPENDS += "rpm" or something.

BOOTSTRAP_EXTRA_RDEPENDS is a remnant. We wouldn't want them controlling it from there anyway. The fact that I INHERIT package_ipk doesn't mean I'm constructing an ipk image, only that I'm *emitting* packages of that format. IMAGE_PKGTYPE controls which rootfs_* bbclass will be used to construct the image, but that doesn't control which package *manager* for that type will be used, nor whether it should be installed at all (ONLINE_PACKAGE_MANAGEMENT).

Signature · 5 lines
Christopher Larson
clarson at kergoth dot com
Founder - BitBake, OpenEmbedded, OpenZaurus
Maintainer - Tslib
Senior Software Engineer, Mentor Graphics
#6 lore raw
Quoted 8 lines · Chris Larson

BOOTSTRAP_EXTRA_RDEPENDS is a remnant.  We wouldn't want them controlling it from there anyway.  The fact that I INHERIT package_ipk doesn't mean I'm constructing an ipk image, only that I'm *emitting* packages of that format.  IMAGE_PKGTYPE controls which rootfs_* bbclass will be used to construct the image, but that doesn't control which package *manager* for that type will be used, nor whether it should be installed at all (ONLINE_PACKAGE_MANAGEMENT).

Thanks, that does clear up how things are intended to behave. However it doesn't reflect the reality of package_deb.bbclass and package_ipk.bbclass, which both add their package managers to the image unconditionally. i.e. using INHERIT="package_ipk" and ONLINE_PACKAGE_MANAGEMENT="none" will still get you an image with opkg installed.

My intention here is to cut off some of opkg's tentacles in OE. I expect more pruning will be required.

-Graham