[RFC] move to opkg

[RFC] move to opkg

[Koen Kooi]

[-- Attachment #1.1: Type: text/plain, Size: 419 bytes --]

Hi,

Poky just switched to opkg and removed ipkg completely, which I think  
is a good thing, but here's a less drastic patch for OE.

Executive summary: you still get .ipk packages, just as before, only  
your rootfs ends up with opkg.  Things like sharprom-compat and wrt54g- 
oe will continue to work just as before.

I'd like to apply this ASAP if there are no serious complaints.

regards,

Koen



[-- Attachment #1.2: opkg.diff --]
[-- Type: application/octet-stream, Size: 5910 bytes --]

#
# old_revision [7a8e14a3c549cff8b48a1b55c75b9e7c77f0d6b3]
#
# patch "classes/package_ipk.bbclass"
#  from [29c2d1055840133cc3b8317a33dc52aeeb4cd9fc]
#    to [46fbc0933d2ee573d776b79edfa0654cedf36674]
# 
# patch "classes/rootfs_ipk.bbclass"
#  from [bf45905ffdc916560ffe662769f35387e731975b]
#    to [fe6a0f97185a32771d1a2a6f430e63a81fd09e73]
# 
# patch "conf/distro/angstrom-2008.1.conf"
#  from [c5203ad6cf4154e5f329808d72d5564566bb46c7]
#    to [76dc1dbe68cefa065b665303acbbfc4083a771c0]
# 
# patch "packages/tasks/task-base.bb"
#  from [47914cc275060af9ade4a3f8bec2034b23a9e7c6]
#    to [3846bc90772f8374ce01dcb4d89aa7272466eee0]
#
============================================================
--- classes/package_ipk.bbclass	29c2d1055840133cc3b8317a33dc52aeeb4cd9fc
+++ classes/package_ipk.bbclass	46fbc0933d2ee573d776b79edfa0654cedf36674
@@ -1,17 +1,17 @@ IMAGE_PKGTYPE ?= "ipk"
 inherit package
 
 BOOTSTRAP_EXTRA_RDEPENDS += "ipkg-collateral ipkg"
 IMAGE_PKGTYPE ?= "ipk"
 
-IPKGCONF_TARGET = "${STAGING_ETCDIR_NATIVE}/ipkg.conf"
-IPKGCONF_SDK =  "${STAGING_ETCDIR_NATIVE}/ipkg-sdk.conf"
+IPKGCONF_TARGET = "${STAGING_ETCDIR_NATIVE}/opkg.conf"
+IPKGCONF_SDK =  "${STAGING_ETCDIR_NATIVE}/opkg-sdk.conf"
 
 python package_ipk_fn () {
 	from bb import data
 	bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
 }
 
-python package_ipk_install () {
+python package_ipk_install () { 
 	#
 	# Warning - this function is not multimachine safe (see stagingdir reference)!
 	#
@@ -60,8 +60,8 @@ python package_ipk_install () {
 		f = open(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"),"w")
 		f.close()
 
-	ret = os.system('ipkg-cl  -o %s -f %s update' % (rootfs, conffile))
-	ret = os.system('ipkg-cl  -o %s -f %s install %s' % (rootfs, conffile, pkgfn))
+	ret = os.system('opkg-cl  -o %s -f %s update' % (rootfs, conffile))
+	ret = os.system('opkg-cl  -o %s -f %s install %s' % (rootfs, conffile, pkgfn))
 	if (ret != 0 ):
 		raise bb.build.FuncFailed
 }
============================================================
--- classes/rootfs_ipk.bbclass	bf45905ffdc916560ffe662769f35387e731975b
+++ classes/rootfs_ipk.bbclass	fe6a0f97185a32771d1a2a6f430e63a81fd09e73
@@ -5,12 +5,12 @@
 # See image.bbclass for a usage of this.
 #
 
-do_rootfs[depends] += "ipkg-native:do_populate_staging ipkg-utils-native:do_populate_staging"
+do_rootfs[depends] += "opkg-native:do_populate_staging opkg-utils-native:do_populate_staging"
 do_rootfs[recrdeptask] += "do_package_write_ipk"
 
 IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} ${@base_conditional("PACKAGE_INSTALL_NO_DEPS", "1", "-nodeps", "", d)}"
 
-DISTRO_EXTRA_RDEPENDS += " ipkg ipkg-collateral "
+DISTRO_EXTRA_RDEPENDS += " opkg opkg-collateral "
 PACKAGE_INSTALL_NO_DEPS ?= "0"
 
 fakeroot rootfs_ipk_do_rootfs () {
@@ -21,41 +21,43 @@ fakeroot rootfs_ipk_do_rootfs () {
 
 	mkdir -p ${T}
 
-	ipkg-cl ${IPKG_ARGS} update
+	opkg-cl ${IPKG_ARGS} update
 
 	# Uclibc builds don't provide this stuff...
 	if [ x${TARGET_OS} = "xlinux" ] || [ x${TARGET_OS} = "xlinux-gnueabi" ] ; then 
 		if [ ! -z "${LINGUAS_INSTALL}" ]; then
-			ipkg-cl ${IPKG_ARGS} install glibc-localedata-i18n
+			opkg-cl ${IPKG_ARGS} install glibc-localedata-i18n
 			for i in ${LINGUAS_INSTALL}; do
-				ipkg-cl ${IPKG_ARGS} install $i 
+				opkg-cl ${IPKG_ARGS} install $i 
 			done
 		fi
 	fi
 	if [ ! -z "${PACKAGE_INSTALL}" ]; then
-		ipkg-cl ${IPKG_ARGS} install ${PACKAGE_INSTALL}
+		opkg-cl ${IPKG_ARGS} install ${PACKAGE_INSTALL}
 	fi
 
 	export D=${IMAGE_ROOTFS}
 	export OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export IPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
-	mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/ipkg/
-	grep "^arch" ${IPKGCONF_TARGET} >${IMAGE_ROOTFS}${sysconfdir}/ipkg/arch.conf
+	mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/opkg/
+	grep "^arch" ${IPKGCONF_TARGET} >${IMAGE_ROOTFS}${sysconfdir}/opkg/arch.conf
 
-	for i in ${IMAGE_ROOTFS}${libdir}/ipkg/info/*.preinst; do
+	for i in ${IMAGE_ROOTFS}${libdir}/opkg/info/*.preinst; do
 		if [ -f $i ] && ! sh $i; then
-			ipkg-cl ${IPKG_ARGS} flag unpacked `basename $i .preinst`
+			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .preinst`
 		fi
 	done
-	for i in ${IMAGE_ROOTFS}${libdir}/ipkg/info/*.postinst; do
+	for i in ${IMAGE_ROOTFS}${libdir}/opkg/info/*.postinst; do
 		if [ -f $i ] && ! sh $i configure; then
-			ipkg-cl ${IPKG_ARGS} flag unpacked `basename $i .postinst`
+			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .postinst`
 		fi
 	done
 
 	install -d ${IMAGE_ROOTFS}/${sysconfdir}
 	echo ${BUILDNAME} > ${IMAGE_ROOTFS}/${sysconfdir}/version
 
+	rm -f ${IMAGE_ROOTFS}${libdir}/opkg/lists/*
+	
 	${ROOTFS_POSTPROCESS_COMMAND}
 	
 	log_check rootfs 	
@@ -82,5 +84,5 @@ remove_packaging_data_files() {
 }
 
 remove_packaging_data_files() {
-	rm -rf ${IMAGE_ROOTFS}${libdir}/ipkg/
+	rm -rf ${IMAGE_ROOTFS}${libdir}/opkg/
 }
============================================================
--- conf/distro/angstrom-2008.1.conf	c5203ad6cf4154e5f329808d72d5564566bb46c7
+++ conf/distro/angstrom-2008.1.conf	76dc1dbe68cefa065b665303acbbfc4083a771c0
@@ -207,7 +207,7 @@ DISTRO_EXTRA_RDEPENDS += "\
     update-modules \
     ${@base_contains("MACHINE_FEATURES", "screen", "psplash", "",d)} \   
     angstrom-version \
-    opkg-ipkg-compat ${ANGSTROM_FEED_CONFIGS} \
+    opkg ${ANGSTROM_FEED_CONFIGS} \
     util-linux-mount util-linux-umount \
     ${DEBUG_APPS} \
     "
============================================================
--- packages/tasks/task-base.bb	47914cc275060af9ade4a3f8bec2034b23a9e7c6
+++ packages/tasks/task-base.bb	3846bc90772f8374ce01dcb4d89aa7272466eee0
@@ -1,5 +1,5 @@ DESCRIPTION = "Merge machine and distro 
 DESCRIPTION = "Merge machine and distro options to create a basic machine task/package"
-PR = "r63"
+PR = "r64"
 
 inherit task
 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 193 bytes --]

Re: [RFC] move to opkg

[Junqian Gordon Xu]

On 03/18/2008 03:55 AM, Koen Kooi wrote:
> Hi,
> 
> Poky just switched to opkg and removed ipkg completely, which I think is 
> a good thing, but here's a less drastic patch for OE.
> 
> Executive summary: you still get .ipk packages, just as before, only 
> your rootfs ends up with opkg.  Things like sharprom-compat and 
> wrt54g-oe will continue to work just as before.
> 
> I'd like to apply this ASAP if there are no serious complaints.

I don't see any reason why not. Go ahead...

Regards
Gordon

WPkg

[Silvano Catinella]

Hello,

I am writing a new concept package manager, it is born just for my softwares
but perhaps it would be interesting for embedded linux distro. I hope ;-)

Many persons told me: why a new software package manager?? there are already
many!

I had necessity to install a software with many platform dependent components
and some independent one. So because I would not many packages the available
package managers where inadequate. The problem is the same if the software I
want install is composed by a core and many GUI library dependent (eg. GTK, QT,
Motif..), or is the same if I have many different pointer devices (eg. mouse,
pen, joystik..).

In order to have a general solution that allows me to install a software in a
non perfectly defined system I started to write WPkg.

This is basically a framework, the developper can write new plugins to perform
new actions or tests, and inside the package's configuration file he can use
them. The plugins are generic ones and he or others can use them in other
packages.

My first releases was in C/Tcl. The C component was a small xml-database. 
A database is necessary because the plugins can modify the configuration data,
that is read by another plugin... and so on. I have not used one of the many
fast available xml-db because I want a very small and light code.

Now, I am rewriting this component in C/C++, and when I will produce a beta
release I will start to integrate it with the other project parts (C++/C/Tcl).
I will also begin to write a parallel version of Tcl components, but they will
be written in C++, so I will obtain a pure C/C++ code too.

I would ask you if my project could be useful for you.


Thank you for your time.

Best regards

Silvano Catinella
catinella@yahoo.com



      ____________________________________________________________________________________
Never miss a thing.  Make Yahoo your home page. 
http://www.yahoo.com/r/hs

Re: WPkg

[Michael 'Mickey' Lauer]

Hi Silvano,

sounds like an interesting idea. Of course you know that you are competing in 
a tight area. There must be a lot of benefits to make distributions switch 
their package manager.

Good speed though and please keep us posted.

:M:
-- 
Dr. Michael 'Mickey' Lauer | IT-Freelancer | http://www.vanille-media.de

Re: WPkg

[Rod Whitby]

Michael 'Mickey' Lauer wrote:
> sounds like an interesting idea. Of course you know that you are competing in 
> a tight area. There must be a lot of benefits to make distributions switch 
> their package manager.

Also be aware of the name collision with the existing 'wpkg' package 
manager at http://wpkg.org/ ...

-- Rod

Re: WPkg

[Silvano Catinella]

Hi Rod, thank you so much because you have shown me this problem. I did not
know that product. I could change my pkg file extensions.

Please, let me know if my solution could be enough.

Thank you

Bye

Silvano

--- Rod Whitby <rod@whitby.id.au> wrote:

> Michael 'Mickey' Lauer wrote:
> > sounds like an interesting idea. Of course you know that you are competing
> in 
> > a tight area. There must be a lot of benefits to make distributions switch 
> > their package manager.
> 
> Also be aware of the name collision with the existing 'wpkg' package 
> manager at http://wpkg.org/ ...
> 
> -- Rod
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 



      ____________________________________________________________________________________
You rock. That's why Blockbuster's offering you one month of Blockbuster Total Access, No Cost.  
http://tc.deals.yahoo.com/tc/blockbuster/text5.com

Re: [RFC] move to opkg

[Marcin Juszkiewicz]

Dnia Tuesday 18 of March 2008, Koen Kooi napisał:

> Poky just switched to opkg and removed ipkg completely, which I think
> is a good thing, but here's a less drastic patch for OE.
>
> Executive summary: you still get .ipk packages, just as before, only
> your rootfs ends up with opkg.  

And your rootfs is built with opkg-native instead of ipkg-native.

> Things like sharprom-compat and wrt54g-oe will continue to work just 
> as before. 

> I'd like to apply this ASAP if there are no serious complaints.

Few things:

1. There is no such thing as 'opkg-utils' - we still use ipkg-utils-native
   for creating packages.

2. You missed image.bbclass change:

--- a/trunk/meta/classes/image.bbclass
+++ b/trunk/meta/classes/image.bbclass
@@ -85,8 +85,6 @@ fakeroot do_rootfs () {
 
 	insert_feed_uris	
 
-	rm -f ${IMAGE_ROOTFS}${libdir}/ipkg/lists/*
-	
 	${IMAGE_PREPROCESS_COMMAND}
 		
 	export TOPDIR=${TOPDIR}

3. Meta/meta-toolchain.bb recipe also use ipkg and this also was changed
   in Poky.

4. You did not set SRCREV for opkg-sdk recipe.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

    The fact that no one understands you doesn't mean you're an artist.

Re: [RFC] move to opkg

[Koen Kooi]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Marcin Juszkiewicz schreef:

| Few things:
|
| 1. There is no such thing as 'opkg-utils' - we still use ipkg-utils-native
|    for creating packages.

fixed

| 2. You missed image.bbclass change:
|
| --- a/trunk/meta/classes/image.bbclass
| +++ b/trunk/meta/classes/image.bbclass
| @@ -85,8 +85,6 @@ fakeroot do_rootfs () {
|
|  	insert_feed_uris	
|
| -	rm -f ${IMAGE_ROOTFS}${libdir}/ipkg/lists/*
| -	
|  	${IMAGE_PREPROCESS_COMMAND}
|  		
|  	export TOPDIR=${TOPDIR}
|
| 3. Meta/meta-toolchain.bb recipe also use ipkg and this also was changed
|    in Poky.
|
| 4. You did not set SRCREV for opkg-sdk recipe.

attached is a version with a less restricted diff.

regards,

Koen

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH35T0MkyGM64RGpERAhauAJ0ZkGHyEI9jku53+Nx0y3zu6frogACfWUc+
wT4CiDU9QvysZ/CDQk2k6BU=
=Wk/S
-----END PGP SIGNATURE-----

[-- Attachment #2: opkg.patch --]
[-- Type: text/x-patch, Size: 9860 bytes --]

 classes/image.bbclass                |    2 --
 classes/package_ipk.bbclass          |   10 +++++-----
 classes/rootfs_ipk.bbclass           |   28 +++++++++++++++-------------
 conf/distro/angstrom-2008.1.conf     |    2 +-
 conf/distro/include/sane-srcrevs.inc |    1 +
 packages/meta/meta-toolchain.bb      |   12 ++++++------
 packages/tasks/task-base.bb          |    2 +-
 7 files changed, 29 insertions(+), 28 deletions(-)
#
# old_revision [7a8e14a3c549cff8b48a1b55c75b9e7c77f0d6b3]
#
# patch "classes/image.bbclass"
#  from [3ee271e04e5f55aafbefcc98d3e2d4a69568301f]
#    to [0c1a6f9180fa9d934d7f0681f8eb5438047728e6]
# 
# patch "classes/package_ipk.bbclass"
#  from [29c2d1055840133cc3b8317a33dc52aeeb4cd9fc]
#    to [46fbc0933d2ee573d776b79edfa0654cedf36674]
# 
# patch "classes/rootfs_ipk.bbclass"
#  from [bf45905ffdc916560ffe662769f35387e731975b]
#    to [e4ec677fe7591b59875944e027a4a9bfb3d81532]
# 
# patch "conf/distro/angstrom-2008.1.conf"
#  from [c5203ad6cf4154e5f329808d72d5564566bb46c7]
#    to [76dc1dbe68cefa065b665303acbbfc4083a771c0]
# 
# patch "conf/distro/include/sane-srcrevs.inc"
#  from [259383497d4fc0110a4243b6b470ad126dbf39b8]
#    to [00a5872d0c380be7e1be3965a534f859d4a45830]
# 
# patch "packages/meta/meta-toolchain.bb"
#  from [95ccbc599aa34310c2d939504ab869df02206d32]
#    to [b6e5c4c6a79a540177927977ed4d729e0393996e]
# 
# patch "packages/tasks/task-base.bb"
#  from [47914cc275060af9ade4a3f8bec2034b23a9e7c6]
#    to [3846bc90772f8374ce01dcb4d89aa7272466eee0]
#
============================================================
--- classes/image.bbclass	3ee271e04e5f55aafbefcc98d3e2d4a69568301f
+++ classes/image.bbclass	0c1a6f9180fa9d934d7f0681f8eb5438047728e6
@@ -85,8 +85,6 @@ fakeroot do_rootfs () {
 
 	insert_feed_uris	
 
-	rm -f ${IMAGE_ROOTFS}${libdir}/ipkg/lists/*
-	
 	${IMAGE_PREPROCESS_COMMAND}
 		
 	export TOPDIR=${TOPDIR}
============================================================
--- classes/package_ipk.bbclass	29c2d1055840133cc3b8317a33dc52aeeb4cd9fc
+++ classes/package_ipk.bbclass	46fbc0933d2ee573d776b79edfa0654cedf36674
@@ -1,17 +1,17 @@ IMAGE_PKGTYPE ?= "ipk"
 inherit package
 
 BOOTSTRAP_EXTRA_RDEPENDS += "ipkg-collateral ipkg"
 IMAGE_PKGTYPE ?= "ipk"
 
-IPKGCONF_TARGET = "${STAGING_ETCDIR_NATIVE}/ipkg.conf"
-IPKGCONF_SDK =  "${STAGING_ETCDIR_NATIVE}/ipkg-sdk.conf"
+IPKGCONF_TARGET = "${STAGING_ETCDIR_NATIVE}/opkg.conf"
+IPKGCONF_SDK =  "${STAGING_ETCDIR_NATIVE}/opkg-sdk.conf"
 
 python package_ipk_fn () {
 	from bb import data
 	bb.data.setVar('PKGFN', bb.data.getVar('PKG',d), d)
 }
 
-python package_ipk_install () {
+python package_ipk_install () { 
 	#
 	# Warning - this function is not multimachine safe (see stagingdir reference)!
 	#
@@ -60,8 +60,8 @@ python package_ipk_install () {
 		f = open(os.path.join(tmpdir, "stamps", "IPK_PACKAGE_INDEX_CLEAN"),"w")
 		f.close()
 
-	ret = os.system('ipkg-cl  -o %s -f %s update' % (rootfs, conffile))
-	ret = os.system('ipkg-cl  -o %s -f %s install %s' % (rootfs, conffile, pkgfn))
+	ret = os.system('opkg-cl  -o %s -f %s update' % (rootfs, conffile))
+	ret = os.system('opkg-cl  -o %s -f %s install %s' % (rootfs, conffile, pkgfn))
 	if (ret != 0 ):
 		raise bb.build.FuncFailed
 }
============================================================
--- classes/rootfs_ipk.bbclass	bf45905ffdc916560ffe662769f35387e731975b
+++ classes/rootfs_ipk.bbclass	e4ec677fe7591b59875944e027a4a9bfb3d81532
@@ -5,12 +5,12 @@
 # See image.bbclass for a usage of this.
 #
 
-do_rootfs[depends] += "ipkg-native:do_populate_staging ipkg-utils-native:do_populate_staging"
+do_rootfs[depends] += "opkg-native:do_populate_staging ipkg-utils-native:do_populate_staging"
 do_rootfs[recrdeptask] += "do_package_write_ipk"
 
 IPKG_ARGS = "-f ${IPKGCONF_TARGET} -o ${IMAGE_ROOTFS} ${@base_conditional("PACKAGE_INSTALL_NO_DEPS", "1", "-nodeps", "", d)}"
 
-DISTRO_EXTRA_RDEPENDS += " ipkg ipkg-collateral "
+DISTRO_EXTRA_RDEPENDS += " opkg opkg-collateral "
 PACKAGE_INSTALL_NO_DEPS ?= "0"
 
 fakeroot rootfs_ipk_do_rootfs () {
@@ -21,41 +21,43 @@ fakeroot rootfs_ipk_do_rootfs () {
 
 	mkdir -p ${T}
 
-	ipkg-cl ${IPKG_ARGS} update
+	opkg-cl ${IPKG_ARGS} update
 
 	# Uclibc builds don't provide this stuff...
 	if [ x${TARGET_OS} = "xlinux" ] || [ x${TARGET_OS} = "xlinux-gnueabi" ] ; then 
 		if [ ! -z "${LINGUAS_INSTALL}" ]; then
-			ipkg-cl ${IPKG_ARGS} install glibc-localedata-i18n
+			opkg-cl ${IPKG_ARGS} install glibc-localedata-i18n
 			for i in ${LINGUAS_INSTALL}; do
-				ipkg-cl ${IPKG_ARGS} install $i 
+				opkg-cl ${IPKG_ARGS} install $i 
 			done
 		fi
 	fi
 	if [ ! -z "${PACKAGE_INSTALL}" ]; then
-		ipkg-cl ${IPKG_ARGS} install ${PACKAGE_INSTALL}
+		opkg-cl ${IPKG_ARGS} install ${PACKAGE_INSTALL}
 	fi
 
 	export D=${IMAGE_ROOTFS}
 	export OFFLINE_ROOT=${IMAGE_ROOTFS}
 	export IPKG_OFFLINE_ROOT=${IMAGE_ROOTFS}
-	mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/ipkg/
-	grep "^arch" ${IPKGCONF_TARGET} >${IMAGE_ROOTFS}${sysconfdir}/ipkg/arch.conf
+	mkdir -p ${IMAGE_ROOTFS}${sysconfdir}/opkg/
+	grep "^arch" ${IPKGCONF_TARGET} >${IMAGE_ROOTFS}${sysconfdir}/opkg/arch.conf
 
-	for i in ${IMAGE_ROOTFS}${libdir}/ipkg/info/*.preinst; do
+	for i in ${IMAGE_ROOTFS}${libdir}/opkg/info/*.preinst; do
 		if [ -f $i ] && ! sh $i; then
-			ipkg-cl ${IPKG_ARGS} flag unpacked `basename $i .preinst`
+			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .preinst`
 		fi
 	done
-	for i in ${IMAGE_ROOTFS}${libdir}/ipkg/info/*.postinst; do
+	for i in ${IMAGE_ROOTFS}${libdir}/opkg/info/*.postinst; do
 		if [ -f $i ] && ! sh $i configure; then
-			ipkg-cl ${IPKG_ARGS} flag unpacked `basename $i .postinst`
+			opkg-cl ${IPKG_ARGS} flag unpacked `basename $i .postinst`
 		fi
 	done
 
 	install -d ${IMAGE_ROOTFS}/${sysconfdir}
 	echo ${BUILDNAME} > ${IMAGE_ROOTFS}/${sysconfdir}/version
 
+	rm -f ${IMAGE_ROOTFS}${libdir}/opkg/lists/*
+	
 	${ROOTFS_POSTPROCESS_COMMAND}
 	
 	log_check rootfs 	
@@ -82,5 +84,5 @@ remove_packaging_data_files() {
 }
 
 remove_packaging_data_files() {
-	rm -rf ${IMAGE_ROOTFS}${libdir}/ipkg/
+	rm -rf ${IMAGE_ROOTFS}${libdir}/opkg/
 }
============================================================
--- conf/distro/angstrom-2008.1.conf	c5203ad6cf4154e5f329808d72d5564566bb46c7
+++ conf/distro/angstrom-2008.1.conf	76dc1dbe68cefa065b665303acbbfc4083a771c0
@@ -207,7 +207,7 @@ DISTRO_EXTRA_RDEPENDS += "\
     update-modules \
     ${@base_contains("MACHINE_FEATURES", "screen", "psplash", "",d)} \   
     angstrom-version \
-    opkg-ipkg-compat ${ANGSTROM_FEED_CONFIGS} \
+    opkg ${ANGSTROM_FEED_CONFIGS} \
     util-linux-mount util-linux-umount \
     ${DEBUG_APPS} \
     "
============================================================
--- conf/distro/include/sane-srcrevs.inc	259383497d4fc0110a4243b6b470ad126dbf39b8
+++ conf/distro/include/sane-srcrevs.inc	00a5872d0c380be7e1be3965a534f859d4a45830
@@ -138,6 +138,7 @@ SRCREV_pn-opkg-native ?= "4142"
 SRCREV_pn-openocd-native ?= "206"
 SRCREV_pn-opkg ?= "4142"
 SRCREV_pn-opkg-native ?= "4142"
+SRCREV_pn-opkg-sdk ?= "4142"
 SRCREV_pn-oprofileui ?= "160"
 SRCREV_pn-psplash ?= "249"
 SRCREV_pn-pylgrim ?= "20"
============================================================
--- packages/meta/meta-toolchain.bb	95ccbc599aa34310c2d939504ab869df02206d32
+++ packages/meta/meta-toolchain.bb	b6e5c4c6a79a540177927977ed4d729e0393996e
@@ -1,6 +1,6 @@ LICENSE = "MIT"
 DESCRIPTION = "Meta package for building a installable toolchain"
 LICENSE = "MIT"
-DEPENDS = "ipkg-native ipkg-utils-native fakeroot-native sed-native"
+DEPENDS = "opkg-native ipkg-utils-native fakeroot-native sed-native"
 
 inherit sdk meta
 
@@ -9,8 +9,8 @@ SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
 SDK_OUTPUT2 = "${SDK_DIR}/image-extras"
 SDK_DEPLOY = "${TMPDIR}/deploy/sdk"
 
-IPKG_HOST = "ipkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
-IPKG_TARGET = "ipkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/temp-target"
+IPKG_HOST = "opkg-cl -f ${IPKGCONF_SDK} -o ${SDK_OUTPUT}"
+IPKG_TARGET = "opkg-cl -f ${IPKGCONF_TARGET} -o ${SDK_OUTPUT}/temp-target"
 
 TOOLCHAIN_HOST_TASK ?= "task-sdk-host"
 TOOLCHAIN_TARGET_TASK ?= "task-sdk-bare"
@@ -40,8 +40,8 @@ do_populate_sdk() {
 	mkdir -p ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/include
 	mkdir -p ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/lib/.debug/
 	mkdir -p ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/share
-	mv ${SDK_OUTPUT}/temp-target/usr/lib/ipkg/status ${SDK_OUTPUT}/${prefix}/package-status
-	rm -rf ${SDK_OUTPUT}/temp-target/usr/lib/ipkg/
+	mv ${SDK_OUTPUT}/temp-target/usr/lib/opkg/status ${SDK_OUTPUT}/${prefix}/package-status
+	rm -rf ${SDK_OUTPUT}/temp-target/usr/lib/opkg/
 	cp -pPR ${SDK_OUTPUT}/temp-target/usr/include/* ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/include/
 	cp -pPR ${SDK_OUTPUT}/temp-target/usr/lib/* ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/lib/
 	if [ -d ${SDK_OUTPUT}/temp-target/usr/lib/.debug ]; then
@@ -69,7 +69,7 @@ do_populate_sdk() {
 	echo 'GROUP ( libc.so.6 libc_nonshared.a )' > ${SDK_OUTPUT}/${prefix}/${TARGET_SYS}/lib/libc.so
 
 	# remove unwanted housekeeping files
-	mv ${SDK_OUTPUT}/usr/lib/ipkg/status ${SDK_OUTPUT}/${prefix}/package-status-host
+	mv ${SDK_OUTPUT}/usr/lib/opkg/status ${SDK_OUTPUT}/${prefix}/package-status-host
 	rm -Rf ${SDK_OUTPUT}/usr/lib
 
 	# extract and store ipks, pkgdata and shlibs data
============================================================
--- packages/tasks/task-base.bb	47914cc275060af9ade4a3f8bec2034b23a9e7c6
+++ packages/tasks/task-base.bb	3846bc90772f8374ce01dcb4d89aa7272466eee0
@@ -1,5 +1,5 @@ DESCRIPTION = "Merge machine and distro 
 DESCRIPTION = "Merge machine and distro options to create a basic machine task/package"
-PR = "r63"
+PR = "r64"
 
 inherit task
 

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
| Marcin Juszkiewicz schreef:
|
| | Few things:
| |
| | 1. There is no such thing as 'opkg-utils' - we still use
| ipkg-utils-native
| |    for creating packages.
|
| fixed
|
| | 2. You missed image.bbclass change:
| |
| | --- a/trunk/meta/classes/image.bbclass
| | +++ b/trunk/meta/classes/image.bbclass
| | @@ -85,8 +85,6 @@ fakeroot do_rootfs () {
| |
| |      insert_feed_uris
| |
| | -    rm -f ${IMAGE_ROOTFS}${libdir}/ipkg/lists/*
| | -
| |      ${IMAGE_PREPROCESS_COMMAND}
| |
| |      export TOPDIR=${TOPDIR}
| |
| | 3. Meta/meta-toolchain.bb recipe also use ipkg and this also was changed
| |    in Poky.
| |
| | 4. You did not set SRCREV for opkg-sdk recipe.
|
| attached is a version with a less restricted diff.

And as a bonus:

http://rafb.net/p/mDhfsf98.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH35yjMkyGM64RGpERAuT4AJ9bij15JKWg41sV8D2OE2IBqYKu7ACfd5UT
l9gU6J46yLMrMQ39d0b7n+Q=
=8xzM
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Jacob Thebault-Spieker]

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

Don't know if my opinion matters that much, but +1 from me

--
Jacob Thebault-Spieker
Cell: (207) 717-5114


Koen Kooi wrote:
> Koen Kooi schreef:
> | Marcin Juszkiewicz schreef:
> |
> | | Few things:
> | |
> | | 1. There is no such thing as 'opkg-utils' - we still use
> | ipkg-utils-native
> | |    for creating packages.
> |
> | fixed
> |
> | | 2. You missed image.bbclass change:
> | |
> | | --- a/trunk/meta/classes/image.bbclass
> | | +++ b/trunk/meta/classes/image.bbclass
> | | @@ -85,8 +85,6 @@ fakeroot do_rootfs () {
> | |
> | |      insert_feed_uris
> | |
> | | -    rm -f ${IMAGE_ROOTFS}${libdir}/ipkg/lists/*
> | | -
> | |      ${IMAGE_PREPROCESS_COMMAND}
> | |
> | |      export TOPDIR=${TOPDIR}
> | |
> | | 3. Meta/meta-toolchain.bb recipe also use ipkg and this also was changed
> | |    in Poky.
> | |
> | | 4. You did not set SRCREV for opkg-sdk recipe.
> |
> | attached is a version with a less restricted diff.
> 
> And as a bonus:
> 
> http://rafb.net/p/mDhfsf98.txt

_______________________________________________
Openembedded-devel mailing list
Openembedded-devel@lists.openembedded.org
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 265 bytes --]

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
| Hi,
|
| Poky just switched to opkg and removed ipkg completely, which I think is
| a good thing, but here's a less drastic patch for OE.
|
| Executive summary: you still get .ipk packages, just as before, only
| your rootfs ends up with opkg.  Things like sharprom-compat and
| wrt54g-oe will continue to work just as before.

Current version with comments from Richard and Marcin addressed:

http://dominion.thruhere.net/koen/OE/opkg/opkg-r7.patch

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH36q4MkyGM64RGpERAqPSAJ0acfcg7amBlmepC8G/U5Hqe/H/GwCfVaEq
InhHTygWuDEDeSdwYzN14gQ=
=d8at
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Geoffrey Wossum]

On Tuesday 18 March 2008 03:55:01 am Koen Kooi wrote:

> Poky just switched to opkg and removed ipkg completely, which I think
> is a good thing, but here's a less drastic patch for OE.
>
> Executive summary: you still get .ipk packages, just as before, only
> your rootfs ends up with opkg.  Things like sharprom-compat and wrt54g-
> oe will continue to work just as before.

I understand that opkg is a fork of ipkg, since ipkg was unmaintained.  But 
could someone explain what, if anything, this means to me as someone 
currently building a product using OpenEmbedded for the underpinning?

TIA!
---
Geoffrey

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Geoffrey Wossum schreef:
| On Tuesday 18 March 2008 03:55:01 am Koen Kooi wrote:
|
|> Poky just switched to opkg and removed ipkg completely, which I think
|> is a good thing, but here's a less drastic patch for OE.
|>
|> Executive summary: you still get .ipk packages, just as before, only
|> your rootfs ends up with opkg.  Things like sharprom-compat and wrt54g-
|> oe will continue to work just as before.
|
| I understand that opkg is a fork of ipkg, since ipkg was unmaintained.
  But
| could someone explain what, if anything, this means to me as someone
| currently building a product using OpenEmbedded for the underpinning?

It means that after this gets applied you login to your product:

ssh user@mytarget
$ su -
Password:
# ipkg update
sh: ipkg: : command not found
# opkg update
<output of opkg downloading stuff from feeds>

So from a device user POV you need to type 'opkg' instead of 'ipkg'.
~From a developer POV you gain PGP signed packages.

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH39JrMkyGM64RGpERAmKCAJ9TEa1Lc14I+56/kG1VJzoMxIK/YACgsoSj
kqU/F8b00r1UGO/BsO9HwXE=
=G4ag
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Richard Purdie]

On Tue, 2008-03-18 at 15:32 +0100, Koen Kooi wrote:
> Geoffrey Wossum schreef:
> | I understand that opkg is a fork of ipkg, since ipkg was unmaintained.
>   But
> | could someone explain what, if anything, this means to me as someone
> | currently building a product using OpenEmbedded for the underpinning?
> 
> It means that after this gets applied you login to your product:
> 
> ssh user@mytarget
> $ su -
> Password:
> # ipkg update
> sh: ipkg: : command not found
> # opkg update
> <output of opkg downloading stuff from feeds>
> 
> So from a device user POV you need to type 'opkg' instead of 'ipkg'.
> ~From a developer POV you gain PGP signed packages.

That isn't the full story since the config files moved
from /usr/lib/ipkg to /usr/lib/opkg and distro maintainers need to be
wary of the transition. I think Angstrom has something to help with this
but I'm not sure?

While I think about this, would now be a good time to move the config
files to /var instead of /usr? 

Poky can't do that yet since we don't have the var changes in OE but I
think most of /var in OE is persistent now?

Cheers,

Richard

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Richard Purdie schreef:
| On Tue, 2008-03-18 at 15:32 +0100, Koen Kooi wrote:
|> Geoffrey Wossum schreef:
|> | I understand that opkg is a fork of ipkg, since ipkg was unmaintained.
|>   But
|> | could someone explain what, if anything, this means to me as someone
|> | currently building a product using OpenEmbedded for the underpinning?
|>
|> It means that after this gets applied you login to your product:
|>
|> ssh user@mytarget
|> $ su -
|> Password:
|> # ipkg update
|> sh: ipkg: : command not found
|> # opkg update
|> <output of opkg downloading stuff from feeds>
|>
|> So from a device user POV you need to type 'opkg' instead of 'ipkg'.
|> ~From a developer POV you gain PGP signed packages.
|
| That isn't the full story since the config files moved
| from /usr/lib/ipkg to /usr/lib/opkg and distro maintainers need to be
| wary of the transition. I think Angstrom has something to help with this
| but I'm not sure?

There is opkg-ipkg-compat.bb and angstrom-feed-configs.bb to help with a
dual system, and opkg-r10.patch moves angstrom over to opkg completely.

| While I think about this, would now be a good time to move the config
| files to /var instead of /usr?

I have no strong opinion on that.

regards,

Koen

| Poky can't do that yet since we don't have the var changes in OE but I
| think most of /var in OE is persistent now?
|
| Cheers,
|
| Richard

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD4DBQFH3/ZfMkyGM64RGpERAp/pAKCBr14wI9/P6z9tc38Xa2w/dIXZZQCXUx6i
L5hGyxpIf+jsTbuI54y8MA==
=eF5Z
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Mike (mwester)]

Koen Kooi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Richard Purdie schreef:
> | On Tue, 2008-03-18 at 15:32 +0100, Koen Kooi wrote:
> |> Geoffrey Wossum schreef:
> |> | I understand that opkg is a fork of ipkg, since ipkg was unmaintained.
> |>   But
> |> | could someone explain what, if anything, this means to me as someone
> |> | currently building a product using OpenEmbedded for the underpinning?
> |>
> |> It means that after this gets applied you login to your product:
> |>
> |> ssh user@mytarget
> |> $ su -
> |> Password:
> |> # ipkg update
> |> sh: ipkg: : command not found
> |> # opkg update
> |> <output of opkg downloading stuff from feeds>
> |>
> |> So from a device user POV you need to type 'opkg' instead of 'ipkg'.
> |> ~From a developer POV you gain PGP signed packages.
> |
> | That isn't the full story since the config files moved
> | from /usr/lib/ipkg to /usr/lib/opkg and distro maintainers need to be
> | wary of the transition.

!!  There's the understatement of the year!!

  I think Angstrom has something to help with this
> | but I'm not sure?
> 
> There is opkg-ipkg-compat.bb and angstrom-feed-configs.bb to help with a
> dual system, and opkg-r10.patch moves angstrom over to opkg completely.

I don't know what this means.  What do I do with these recipes?  I just 
want to get ipkg working again.

The latest builds of SlugOS seem to have ended up with a broken mix of 
ipkg and opkg stuff.  The feeds config files are in /etc/opkg; but 
/lib/ipkg still exists.  The ipkg command is very much still present, so 
I assume that Koen's example above requires that the distro maintainer 
(that would be me) has to do something.  The opkg utility is also 
present, and seems to work better than ipkg -- opkg downloads stuff, and 
dies when it runs the post-configure scripts.

> | While I think about this, would now be a good time to move the config
> | files to /var instead of /usr?
> 
> I have no strong opinion on that.
> 
> regards,
> 
> Koen
> 
> | Poky can't do that yet since we don't have the var changes in OE but I
> | think most of /var in OE is persistent now?
> |
> | Cheers,
> |
> | Richard
> 

Sorry for the late email on this thread.  I saw this, and made a note 
that we'd like to switch to opkg at some point.  I just didn't expect 
that it would end up pushed into the distro without some type of action 
on my part to enable this (disruptive) change.

On which mailing list was the technical discussion on how opkg worked, 
why opkg, and what distro maintainers should do to ensure that ipkg 
continued to work, or that the opkg transition went smoothly?  I can't 
find such a discussion on the various archives.

Regards
Mike (mwester)

Re: [RFC] move to opkg

[Mike (mwester)]

Here's what I've found out: There is no such thing as a 
"PREFERRED_VERSION" or "PREFERRED_PROVIDER" solution for this ipkg/opkg 
problem.  A simple grep tells us why (some random lines I picked out of 
the output from grep):

classes/image.bbclass:          echo "src/gz local-$arch 
${FEED_DEPLOYDIR_BASE_URI}/$arch" >> 
${IMAGE_ROOTFS}/etc/opkg/local-$arch-feed.conf
classes/rootfs_ipk.bbclass:                     opkg-cl ${IPKG_ARGS} 
flag unpacked `basename $i .postinst`

etc, etc -- it's pretty clear that opkg is hardcoded all over the place.



So it seems that everyone *MUST* comply, and migrate to opkg -- unless 
you want to just freeze your distro on an old version of OE.

Now after several hours trying to figure out what to do with this opkg 
stuff, it seems that there's something that is supposed to make 
compatability possible, although there are no documents anywhere on this 
.  So I added opkg-ipkg-compat to task-slugos.bb, and bumped the PR.

Here's what it has started to add to the image (there may be more than 
this):

libgpg
libgpg-error
libcrypt
lzo
pth
libassuan
gnutls


We have a grand total of 8 MBytes of flash on this device; space is at a 
premium -- I don't think that ipkg was so bad that we should be adding 
all of this to the image!  What should we remove to make room for these 
libraries?  The kernel?  Maybe we don't need busybox.  I guess if we 
require a soldered-on serial port, we *could* get rid of openssh...

I hope I'm exaggerating and these libraries aren't that huge, but still, 
we fight for every 10KByte chunk of flash we can get back, and opkg 
seems like a huge, and terribly painful loss.

In the short term:

A) Where are the docs on opkg?
B) How does one modify distros to live in the new world order that's 
been decreed?
C) How much "fat" can we trim off of opkg, and how do we do that, so 
that we don't have to throw out other niceties that users appreciate?

And in the long term:
How do we go about setting up fixing all this opkg stuff so that we 
properly abstract it, allowing a distro to select ipkg, opkg, upkg, and 
sometimes-ypkg that they desire?

Thanks
Mike (mwester)

Re: [RFC] move to opkg

[Marcin Juszkiewicz]

Dnia Sunday 23 of March 2008, Mike (mwester) napisał:
> Here's what it has started to add to the image (there may be more than
> this):
>
> libgpg
> libgpg-error
> libcrypt
> lzo
> pth
> libassuan
> gnutls

> In the short term:
>
> A) Where are the docs on opkg?

I do not have idea is there any at all ;(

> C) How much "fat" can we trim off of opkg, and how do we do that, so
> that we don't have to throw out other niceties that users appreciate?

Someone can add "opkg-lowfat_svn.bb":

--code--
require opkg_svn.bb
EXTRA_OECONF += "--disable-gpg"
--code--

And proper PREFERRED_PROVIDER stuff. This recipe will not fetch all those 
libraries which you listed - only libcurl with dependencies will be 
added.

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

      I don't know. I don't care. And it doesn't make any difference.

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mike (mwester) schreef:
| Here's what I've found out: There is no such thing as a
| "PREFERRED_VERSION" or "PREFERRED_PROVIDER" solution for this ipkg/opkg
| problem.  A simple grep tells us why (some random lines I picked out of
| the output from grep):
|
| classes/image.bbclass:          echo "src/gz local-$arch
| ${FEED_DEPLOYDIR_BASE_URI}/$arch" >>
| ${IMAGE_ROOTFS}/etc/opkg/local-$arch-feed.conf
| classes/rootfs_ipk.bbclass:                     opkg-cl ${IPKG_ARGS}
| flag unpacked `basename $i .postinst`
|
| etc, etc -- it's pretty clear that opkg is hardcoded all over the place.

And that used to be ipkg hardcoded all over the place.

| So it seems that everyone *MUST* comply, and migrate to opkg -- unless
| you want to just freeze your distro on an old version of OE.

Or use the stable branch? The stable branch seems to fit your needs:
It's available, it's maintained and changes can only go in through a
public and open review process.

| Now after several hours trying to figure out what to do with this opkg
| stuff, it seems that there's something that is supposed to make
| compatability possible, although there are no documents anywhere on this
| .  So I added opkg-ipkg-compat to task-slugos.bb, and bumped the PR.

opkg-ipkg-compat is to make opkg work on an ipkg system, not the other
way around. What you are after is something that symlinks /usr/lib/opkg
- -> /usr/lib/ipkg, /etc/opkg -> /etc/ipkg, adds opkg to PACKAGE_REMOVE
(like in liveramdisk-image.bb) etc

| A) Where are the docs on opkg?

Mickeyl sent a mail to this list about that over a month ago.

| B) How does one modify distros to live in the new world order that's
| been decreed?

Dunno, that's up to the distro maintainer. I can only say "look at poky"
or "look at angstrom"

| And in the long term:
| How do we go about setting up fixing all this opkg stuff so that we
| properly abstract it, allowing a distro to select ipkg, opkg, upkg, and
| sometimes-ypkg that they desire?

You mean something like ANGSTROM_PKG_FORMAT angstrom has?

I believe these sorts of problems stem from the fact that you don't have
the time to keep up with the pace of .dev, so I really think distros
like unslung are better of using the stable branch, instead of wasting
energy trying to keep up with .dev.
That being said, I don't think OE developers sit at their desks trying
to thinks how to make life difficult for distro maintainer.

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH5ji1MkyGM64RGpERAleXAKCG6zs+uvNe2GoQ4yA6bSxsqkBFPgCgjbiV
TTQcY/o1f7WLjd276t2S+Lo=
=PsdH
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Mike (mwester)]

Koen Kooi wrote:
...
> I believe these sorts of problems stem from the fact that you don't have
> the time to keep up with the pace of .dev, 

Bullshit.  You sent the RFC on Tuesday, with ZERO documentation on the 
impact.  See the email chain -- you were practically evasive on the 
impact to distro maintainers.  You them made the change on before even a 
week had gone by, a holiday weekend at that.  Actually it was closer to 
4 days (total) and no documentation at all for anyone to assess the impact.

No, the problem is that YOU didn't take the time to wait before you 
jammed a totally undocumented and insufficently-understood 
highly-invasive change onto the entire community!

so I really think distros
> like unslung are better of using the stable branch, instead of wasting
> energy trying to keep up with .dev.
You just jumped to a conclusion.  Unslung was mentioned ONCE.  This is 
the SlugOS distro - I haven't even gotten to try to untangle Unslung yet.

And no, this change was not yet ready for .dev -- this should have been 
on a branch where it could have been tested against other distros. 
Don't shove your pushing of an unfinished bit of work onto anyone else 
as their fault.

> That being said, I don't think OE developers sit at their desks trying
> to thinks how to make life difficult for distro maintainer.

Nope.  I don't think that either.  I think that merely one particular 
change got pushed because one particular developer decided it was too 
difficult for him to document more thoroughly and was too impatient to 
wait for more feedback.

> Koen

Now, how about a helpful email?  You sent your email accusing me of 
being to lazy and unable to keep up with .dev.  I've responded in kind 
with my email.  Koen, how about solving a problem instead of just trying 
to blame me?

Mike (mwester)

Re: [RFC] move to opkg

[Tom Rini]

On Sun, Mar 23, 2008 at 12:02:13PM +0100, Koen Kooi wrote:

> Or use the stable branch? The stable branch seems to fit your needs:
> It's available, it's maintained and changes can only go in through a
> public and open review process.

So you're saying that opkg will move to the stable branch once someone
documents how to update distros for it?  Great!  Now that the first two
(Angstrom and Poky) are done, you guys can all work together on getting
SlugOS and Unslung updated, and make some notes of that as you go along.

-- 
Tom Rini

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tom Rini schreef:
| On Sun, Mar 23, 2008 at 12:02:13PM +0100, Koen Kooi wrote:
|
|> Or use the stable branch? The stable branch seems to fit your needs:
|> It's available, it's maintained and changes can only go in through a
|> public and open review process.
|
| So you're saying that opkg will move to the stable branch once someone
| documents how to update distros for it?

No, it can go into the stable branch once the steps in
http://linuxtogo.org/gowiki/Angstrom/Backport_from_dev_to_stable have
been satisfied.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH5qegMkyGM64RGpERAvD8AKCXe8Hb6jG/z+Wy58ZHq3IEaxh2qACcC5Vg
D8hGNopYpN2AK4g7pEu9Pkg=
=Z2cj
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Tom Rini]

On Sun, Mar 23, 2008 at 07:55:28PM +0100, Koen Kooi wrote:
> Tom Rini schreef:
> | On Sun, Mar 23, 2008 at 12:02:13PM +0100, Koen Kooi wrote:
> |
> |> Or use the stable branch? The stable branch seems to fit your needs:
> |> It's available, it's maintained and changes can only go in through a
> |> public and open review process.
> |
> | So you're saying that opkg will move to the stable branch once someone
> | documents how to update distros for it?
> 
> No, it can go into the stable branch once the steps in
> http://linuxtogo.org/gowiki/Angstrom/Backport_from_dev_to_stable have
> been satisfied.

Well, presumably there will be another stable branch declared at some
point and my main point holds.  Lets use this as a chance to document
how to move a distro up to opkg from ipkg, and maybe sort out the kinks
(such as say making it easy at the distro level to turn off GPG if size
is more important than signing).

-- 
Tom Rini

Re: [RFC] move to opkg

[Rod Whitby]

Tom Rini wrote:
> On Sun, Mar 23, 2008 at 07:55:28PM +0100, Koen Kooi wrote:
>> Tom Rini schreef:
>> | On Sun, Mar 23, 2008 at 12:02:13PM +0100, Koen Kooi wrote:
>> |
>> |> Or use the stable branch? The stable branch seems to fit your needs:
>> |> It's available, it's maintained and changes can only go in through a
>> |> public and open review process.
>> |
>> | So you're saying that opkg will move to the stable branch once someone
>> | documents how to update distros for it?
>>
>> No, it can go into the stable branch once the steps in
>> http://linuxtogo.org/gowiki/Angstrom/Backport_from_dev_to_stable have
>> been satisfied.
> 
> Well, presumably there will be another stable branch declared at some
> point and my main point holds.  Lets use this as a chance to document
> how to move a distro up to opkg from ipkg, and maybe sort out the kinks
> (such as say making it easy at the distro level to turn off GPG if size
> is more important than signing).

Tom,

Unfortunately, that's not how Koen works.  He pushes something through 
with no regard for impact on other distros, as long as it works for the 
small set of distros that he personally uses.  Then he just blames 
everyone else for not keeping up instead of giving assistance to others.

So unless anyone else did the work to reverse-engineer how to move from 
ipkg to opkg, those with the knowledge of how to do so already will just 
keep maintaining their own favourite distros with no regard to the fact 
that they broke a number of other distros in OE, and when the time comes 
to cut the next stable branch they will say "oh, you didn't keep up with 
the changes, so you won't be part of this stable branch".

-- Rod (who is in favour of opkg, if deployed in a well-managed fashion)

Re: [RFC] move to opkg

[Richard Purdie]

I'm not going to comment specifically on the various aspects of this
thread, it makes depressing reading and I can sympathise with the
various sides.

Yes, there is a strong desire to remove ipkg from OE entirely from
certain parties and the reasons are political and complicated since
there is a lot of history involved. Personally I'm on the fence, ipkg is
a known quantity, bugs and all but I can see benefits of opkg.

Personally I wasn't particularly keen on changing Poky but others were
and I have other things that I feel more strongly about to expend energy
on so Poky changed. I don't have a problem with the changes in Poky, I'm
not sure that change should have rolled into OE quite as quickly
however.

The main problem is the situation that OE has left some distributions
in. Opkg is not compatible with ipkg despite their similarities due to
the changed files locations. We've therefore just forced a massive ABI
change on users and I'm not sure the consequences have been considered
and it did need more discussion than it got :/. Solutions to the issues
were certainly not mentioned in the discussion although I did hint at
the problems.

Where do we go from here?

Judging from the comments we have some people who want to continue to
use ipkg, is OE.dev going to support that? I know what several people
are going to answer and there is going to be a conflict here :(. There
is no technical reason both ipkg and opkg can't be in OE.dev with the
appropriate magic.

This does raise the question of whether basing a distribution directly
off .dev is a good idea? I know some people do, I also know its called
the OE development branch for a reason.

The thing is I don't think this is a technical problem, its more a
question about how OE.dev is managed and who can do what and how. If we
all had to write down the aims and objectives of OE.dev, every one would
be different :/.

I could wade into this discussion as I've done in others but I don't
particularly want to and I'd prefer to let someone else deal with it.
I've already wasted far too much time trying to type this so far, this
is about the 3rd version since I'm not getting across what I think is
the right message to all parties :/.

The battering I've had recently on list, off list and on irc are enough
to make me seriously consider why I do what I do and whether I want to
continue doing it.

Richard - wishing everyone could coexist

Re: [RFC] move to opkg

[Rod Whitby]

Richard Purdie wrote:
> Judging from the comments we have some people who want to continue to
> use ipkg, is OE.dev going to support that? I know what several people
> are going to answer and there is going to be a conflict here :(. There
> is no technical reason both ipkg and opkg can't be in OE.dev with the
> appropriate magic.

I personally would be happy to use opkg on .dev, if the transition to it 
was managed properly.  ipkg has been stagnant for some years now.

> This does raise the question of whether basing a distribution directly
> off .dev is a good idea? I know some people do, I also know its called
> the OE development branch for a reason.

If you don't base the unstable HEAD of your distribution off .dev, then 
.dev will never get the testing it requires, and you will never be able 
to get your distribution included in the next stable branch.

> The thing is I don't think this is a technical problem, its more a
> question about how OE.dev is managed and who can do what and how. If we
> all had to write down the aims and objectives of OE.dev, every one would
> be different :/.

I think here it is simply a case of some people being unable to say 
"sorry, I made a mistake, lets see how we can fix it" and instead trying 
to point the blame at others.

We all realise that pushing .dev forward will cause breakage, and that 
there should be no stigma associated with that breakage as long as there 
is a transition proposal reviewed on the ML first.  In this instance, 
(as I remember it), there was a proposal to move, but no transition plan 
reviewed.  If there is a transition plan, and implementing that reviewed 
plan causes breakage, then no-one should complain about that, and 
everyone should just put their egos aside and pitch in and help fix the 
problems.  The escalation occurs when people try to deflect the issue on 
to others instead of dealing with it directly in a technical manner.

-- Rod

Re: [RFC] move to opkg

[Mike (mwester)]

Richard Purdie wrote:
> I'm not going to comment specifically on the various aspects of this
> thread, it makes depressing reading and I can sympathise with the
> various sides.

Yes, it's depressing.  So something needs to be done.

> Yes, there is a strong desire to remove ipkg from OE entirely from
> certain parties and the reasons are political and complicated since
> there is a lot of history involved. Personally I'm on the fence, ipkg is
> a known quantity, bugs and all but I can see benefits of opkg.

 From what I know, I suspect opkg would be desirable as well, but we 
lack any information to determine what the cost would be.

Here's my proposed solution: let's revert the opkg changes.  And then 
let's do it right.  I'll be more than happy to drop all project 
activities I have going on right now to assist in a re-do of the opkg 
implementation.

(Conversely, and regrettably, I just don't see that someone telling me 
to reverse-engineer another distro in order for me to get the 
information necessary is going to be accurate, productive, or 
particularly beneficial to me or the community, so that's just not a 
solution.)


But let's leave the ipkg/opkg specifics aside for the moment...

[snip for brevity]

> This does raise the question of whether basing a distribution directly
> off .dev is a good idea? I know some people do, I also know its called
> the OE development branch for a reason.

Dev moves too fast; if a distro is not constantly at the tip of the dev 
branch, it is nearly impossible to get it working again. I know this 
because twice now I've let .dev get ahead of me too far, and it's been a 
real job to catch up.  In fact, if it wasn't for folks like rwhitby who 
took on a lot of the work, we wouldn't have ever caught up from the 
situation where I let several months elapse.

> The thing is I don't think this is a technical problem, its more a
> question about how OE.dev is managed and who can do what and how. If we
> all had to write down the aims and objectives of OE.dev, every one would
> be different :/.

This is probably the root of the problem.

I make an assumption about the gating criteria for entry of a change 
into the .dev branch; it seems this assumption is not shared.

But I did not form these assumptions in a vacuum -- they came from this 
very place -- this mailing list.  Specifically, from the several commits 
I made that upset certain people, who clarified (some more helpfully and 
politely than others, but that's life) what I should have done: to 
ensure that I properly communicated my intent to commit, and that I 
didn't break anyone else's stuff when I finally committed the change. 
I'm merely applying the criteria I was given (multiple times) to this 
situation.

Have we altered this thinking?  Can I now relax my criteria for 
committing changes, too?  Please don't tell me that this is a case where 
special dispensation has been granted for certain distros?

> I could wade into this discussion as I've done in others but I don't
> particularly want to and I'd prefer to let someone else deal with it.
> I've already wasted far too much time trying to type this so far, this
> is about the 3rd version since I'm not getting across what I think is
> the right message to all parties :/.
> 
> The battering I've had recently on list, off list and on irc are enough
> to make me seriously consider why I do what I do and whether I want to
> continue doing it.

I don't see where this is your problem.  In fact, you've been 
extraordinarily helpful in resolving past issues with changes.  You've 
gone above and beyond the call of duty in that regard -- for which I'm 
very grateful.

But where (and who) is the OE core team?  Why are they not enforcing 
some of the rules (or if they prefer, clarifying that .dev is a 
free-for-all)?  Either way would have resolved this issue, which 
primarily resulted from a different expectations of the completeness and 
quality of known-to-be-disruptive changes made on the branch.

> Richard - wishing everyone could coexist

Regards,
Mike (mwester) - wishing for consistency

Re: [RFC] move to opkg

[Stelios Koroneos]

I though a lot whether I should send this email or not and at the end come
up to the conclusion that its better to speak up although I run the risk of
having crowds with pitchforks coming after me :)

Recently I have been working on a part of a project that does not include OE
related development but tried to keep up with what is going on with OE
although not doing any active development, but that allowed me to have a
different perspective on things.

The problem I see is that .dev is turning into .experimental where all kind
of "infrastracture" changes get done with little or no afterthough
I do understand that .dev is just that, a development branch, and so
breakage is expected to happen, but I think recently we are having more days
with .dev in breakage than in a "working" state.

The main reason is that people simply don't use the SCM we have for the
reason we have it.
SCM's exists so,among other things, branches can be made, where experimental
code and "disruptive" changes can exists,without interfearing with the
actual development. 
Then one day these changes can either get merged to the main branch or
cherry pick what ever we want, after things get tested on the branch and
major issues are solved.
I know that the obvious answer to this, is "mtn sucks, we need <put your
favorite scm here>" but I strongly believe it's a matter of workflow and not
tools.
(for the record we use svn internally and mtn was an additional "pain" we
had to go over to use OE)
I've been with OE for the something like 3 years now and I have never seen
any developer create a branch to test big changes (with the exception of the
avr32 work I did with Koen, which by the way had almost 0 infrastracture
changes ) and things simply get "imported" into .dev after a (usually sort)
RFC "period".

The other major issue I see more and more and I am sure we will face more in
the future, is that a lot of these infrastracture changes are coming from
companies that are using OE and are trying to "sync" OE with their
developments than the other way around.
I am not saying this is a bad thing, but I am just wondering what would
happen if for example one of choices they made for their OE based distro was
"not compatible" with the rest distro's or what would happen if the 2 major
commercial entities that use OE now decided to take a totally different
approach on a matter.

Change is a good thing (and that goes for opkg also) but as OE grows larger
we will face these issues more and more, so we better come up with a
solution before things get out of control.

And for closing this, let me clarify that I REALLY don't reffer to any
developer(s) in particular or even the recent opkg issue but it's my view of
what is going on.


Stelios S. Koroneos

Digital OPSiS - Embedded Intelligence
http://www.digital-opsis.com
 

Re: [RFC] move to opkg

[Tom Rini]

On Tue, Mar 18, 2008 at 03:32:11PM +0100, Koen Kooi wrote:

[snip]
> So from a device user POV you need to type 'opkg' instead of 'ipkg'.
> ~From a developer POV you gain PGP signed packages.

So:
- Maintained system (yay)
- PGP signing

Anything else, yet?

-- 
Tom Rini

Re: [RFC] move to opkg

[Mikhail Gusarov]

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

Twas brillig at 11:12:36 18.03.2008 UTC-07 when Tom Rini did gyre and gimble:

 TR> So:
 TR> - Maintained system (yay)
 TR> - PGP signing

 TR> Anything else, yet?

http://wiki.openmoko.org/wiki/Opkg

From "New Features":

* Mark packages that were installed to satisfy dependancies (auto installed)
* Additional command line option to remove "auto installed" packages
* Support for faceted classification (similar to debtags)

-- 

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

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Mikhail Gusarov schreef:
| Twas brillig at 11:12:36 18.03.2008 UTC-07 when Tom Rini did gyre and
gimble:
|
|  TR> So:
|  TR> - Maintained system (yay)
|  TR> - PGP signing
|
|  TR> Anything else, yet?
|
| http://wiki.openmoko.org/wiki/Opkg
|
| From "New Features":
|
| * Mark packages that were installed to satisfy dependancies (auto
installed)
| * Additional command line option to remove "auto installed" packages
| * Support for faceted classification (similar to debtags)

And medium-term I hope this patch gets ported to ipkg:

https://dev.openwrt.org/browser/trunk/package/busybox/patches/524-memory_usage.patch?rev=10125

regards,

Koen
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH4AyLMkyGM64RGpERAqUpAJ4iokTOFFhXStpP59lszHoEqxPIlgCePyMu
p4CUez+wnMnNUqk61zdQtFs=
=gopi
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg

[Richard Purdie]

On Tue, 2008-03-18 at 19:40 +0100, Koen Kooi wrote:
> And medium-term I hope this patch gets ported to ipkg:
> 
> https://dev.openwrt.org/browser/trunk/package/busybox/patches/524-memory_usage.patch?rev=10125

People can propose patches on the opkg mailing list...

Cheers,

Richard

Re: [RFC] move to opkg

[Marcin Juszkiewicz]

Dnia Wednesday 19 of March 2008, Richard Purdie napisał:
> On Tue, 2008-03-18 at 19:40 +0100, Koen Kooi wrote:
> > And medium-term I hope this patch gets ported to ipkg:
> >
> > https://dev.openwrt.org/browser/trunk/package/busybox/patches/524-mem
> >ory_usage.patch?rev=10125
>
> People can propose patches on the opkg mailing list...

And that one was already proposed by me (with few other OpenWRT patches).

-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

          Internet connection is not a license to be an asshole.

Re: [RFC] move to opkg

[Marcin Juszkiewicz]

Dnia Tuesday 18 of March 2008, Geoffrey Wossum napisał:

> I understand that opkg is a fork of ipkg, since ipkg was unmaintained. 
> But could someone explain what, if anything, this means to me as
> someone currently building a product using OpenEmbedded for the
> underpinning?

Two things comes to my mind:

- "opkg" instead of "ipkg" command 
- few libraries more (gpgme + pth) as opkg require them (can be disabled)


-- 
JID: hrw-jabber.org
OpenEmbedded developer/consultant

              there are actually only 10 web sites out there,
              all the others are rearranged copies

Re: [RFC] move to opkg

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Koen Kooi schreef:
| Hi,
|
| Poky just switched to opkg and removed ipkg completely, which I think is
| a good thing, but here's a less drastic patch for OE.
|
| Executive summary: you still get .ipk packages, just as before, only
| your rootfs ends up with opkg.  Things like sharprom-compat and
| wrt54g-oe will continue to work just as before.
|
| I'd like to apply this ASAP if there are no serious complaints.

It's in!
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)

iD8DBQFH4Dt+MkyGM64RGpERAjHCAKC8nwKcHhSTbtNBvebUfo/ze/vrswCfQRdw
6fsNAkZe0OaN81/vIR3bt+c=
=UDKM
-----END PGP SIGNATURE-----

Re: [RFC] move to opkg / md5 error on big-endian machine

[Jeremy Lainé]

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

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

opkg systematically fails to check the MD5 checksums on big-endian
targets. The reason for this is that md5.c was taken from glibc, and
it only sets the endianness correctly if _LIBC is defined:

#ifdef _LIBC
# include <endian.h>
# if __BYTE_ORDER == __BIG_ENDIAN
#  define WORDS_BIGENDIAN 1
# endif
[snip]
#endif

Attached is a patch thats sets WORDS_BIGENDIAN on big-endian machines
without touching the code, and fixes the MD5 errors I was getting.

Rather than putting this patch into OE, maybe we should push this
upstream?

Cheers,

- --
Jeremy LAINE
Bolloré telecom | 11bis, rue Scribe | F-75009 Paris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH4VLbCL1n3lVB9EYRArVFAJ9M22nqlh2jqV+OKg7HqNsgIC/hBgCfa2R8
VdUuk6OIo5W72sXs/8tQ8G8=
=DyiG
-----END PGP SIGNATURE-----


[-- Attachment #2: check_endianness.patch --]
[-- Type: text/x-diff, Size: 1048 bytes --]

diff -urN opkg.orig/configure.ac opkg/configure.ac
--- opkg.orig/configure.ac	2008-03-19 10:43:40.000000000 +0100
+++ opkg/configure.ac	2008-03-19 18:37:08.000000000 +0100
@@ -93,6 +93,10 @@
 AC_TYPE_SIZE_T
 AC_CHECK_MEMBERS([struct stat.st_rdev])
 
+# Checks endianness
+AC_C_BIGENDIAN(ENDIAN_CFLAGS="-DWORDS_BIGENDIAN=1",)
+AC_SUBST(BIGENDIAN_CFLAGS)
+
 # Don't do annoying tests that don't work when cross-compiling, just trust them.
 # The AC_FUNC_MEMCMP test doesn't work during a cross-compile, disable.
 # AC_FUNC_MEMCMP
diff -urN opkg.orig/libopkg/Makefile.am opkg/libopkg/Makefile.am
--- opkg.orig/libopkg/Makefile.am	2008-03-19 10:43:40.000000000 +0100
+++ opkg/libopkg/Makefile.am	2008-03-19 18:36:19.000000000 +0100
@@ -59,7 +59,7 @@
 	$(opkg_cmd_sources) $(opkg_db_sources) \
 	$(opkg_util_sources) $(opkg_list_sources)
 
-libopkg_la_CFLAGS = $(ALL_CFLAGS)  $(CURL_CFLAGS) $(GPGME_CFLAGS)
+libopkg_la_CFLAGS = $(ALL_CFLAGS) $(BIGENDIAN_CFLAGS) $(CURL_CFLAGS) $(GPGME_CFLAGS)
 lib_LTLIBRARIES = libopkg.la
 
 

[-- Attachment #3: check_endianness.patch.sig --]
[-- Type: application/octet-stream, Size: 65 bytes --]

Re: [RFC] move to opkg / md5 error on big-endian machine

[Jeremy Lainé]

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

Thanks for applying the patch to SVN! Unfortunately a typo crept into my
previous patch, attached is a diff against SVN which fixes it.

Cheers,
Jeremy

[-- Attachment #2: fix-endianness.patch --]
[-- Type: text/x-diff, Size: 471 bytes --]

Index: configure.ac
===================================================================
--- configure.ac	(revision 4241)
+++ configure.ac	(working copy)
@@ -94,7 +94,7 @@
 AC_CHECK_MEMBERS([struct stat.st_rdev])
 
 # Checks endianness
-AC_C_BIGENDIAN(ENDIAN_CFLAGS="-DWORDS_BIGENDIAN=1",)
+AC_C_BIGENDIAN(BIGENDIAN_CFLAGS="-DWORDS_BIGENDIAN=1",)
 AC_SUBST(BIGENDIAN_CFLAGS)
 
 # Don't do annoying tests that don't work when cross-compiling, just trust them.

Re: [RFC] move to opkg

[Jeremy Lainé]

Some comments concerning the two following recipes:

- opkg-native_svn.bb
- opkg-sdk_svn.bb

They both add "-disable-gpg" (note the single dash) to EXTRA_OECONF. I
think this should be --disable-gpg if we actually want to disable GPG.

opkg-sdk_svn.bb also adds "--with-opkglibdir=${target_libdir}/opkg" to
EXTRA_OECONF, which looks wrong (I don't think the "opkg" bit should be
there). From the configure.ac:

--with-opkglibdir=DIR   specifies directory to put status and info
files. "/opkg" is always added so if you want your files to be in
/usr/lib/opkg you should indicate --with-opkglibdir=/usr/lib

Cheers,
Jeremy