Skip to contentSkip to conversation

autoconf-archive: inherit allarch and fix package splitting

PATCH In review Chen Qi 5 participants 14 messages Nov 13, 2017 – Nov 15, 2017

lore
Share & tools
lore

Chen Qi

author
#0 lore raw

cover autoconf-archive: inherit allarch and fix package splitting

The following changes since commit 4db3915372228bbe045947333ec3a29785e3da94:

dev-manual: Updated bitbake-layers overview section. (2017-11-12 06:51:20 +0000)

are available in the git repository at:

git://git.pokylinux.org/poky-contrib ChenQi/autoconf-archive-allarch
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=ChenQi/autoconf-archive-allarch

Chen Qi (1):
autoconf-archive: inherit allarch and fix package splitting

 .../autoconf-archive/autoconf-archive_2016.09.16.bb                 | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
Signature · 1 line
1.9.1
author
#1 lore raw

PATCH 1/1 autoconf-archive: inherit allarch and fix package splitting

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

Also fix package splitting. With current package splitting, autoconf-archive itself contains almost nothing, the m4 macros are contained in its dev package. However, autoconf-archive should contain those m4 marcos itself.

Signed-off-by Chen Qi <[email protected]>
---
 .../autoconf-archive/autoconf-archive_2016.09.16.bb                 | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)
meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb +5 -1
index 104dc38..89d57ac 100644
@@ -9,6 +9,10 @@ SRC_URI = "${GNU_MIRROR}/${BPN}/${BPN}-${PV}.tar.xz"
 SRC_URI[md5sum] = "bf19d4cddce260b3c3e1d51d42509071"
 SRC_URI[sha256sum] = "e8f2efd235f842bad2f6938bf4a72240a5e5fcd248e8444335e63beb60fabd82"
 
-inherit autotools
+inherit autotools allarch
+
+PACKAGES = "${PN} ${PN}-doc"
+
+FILES_${PN} += "${datadir}/aclocal"
 
 BBCLASSEXTEND = "native nativesdk"
Signature · 1 line
1.9.1
#2 lore raw

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

I have found previously that when changing a recipe to produce more generic output, like in this case, and the old binary package is still in deploy/, then the package manager would always pick the more specific version, even if a more recent (by package version) exists in deploy. In my case I was moving from PACKAGE_ARCH=${MACHINE_ARCH} to PACKAGE_ARCH=${TUNE_PKGARCH}, but I guess it'll be the same here.

What is the correct way to deal with that other that cleansstate?

Cheers,
Andre'

#3 lore raw

Is this during do_rootfs or are you seeing this issue when upgrading on the target as well?

I haven't found the bug for this but IIRC it's because do_rootfs is using --prefer-arch-to-version parameter. meta/classes/package_ipk.bbclass:OPKG_ARGS += "--force_postinstall --prefer-arch-to-version"
which causes this undesired behavior.

Quoted 24 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

I have found previously that when changing a recipe to produce more generic output, like in this case, and the old binary package is still in deploy/, then the package manager would always pick the more specific version, even if a more recent (by package version) exists in deploy. In my case I was moving from PACKAGE_ARCH=${MACHINE_ARCH} to PACKAGE_ARCH=${TUNE_PKGARCH}, but I guess it'll be the same here.

What is the correct way to deal with that other that cleansstate?

Cheers,
Andre'

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#4 lore raw

opkg --prefer-arch-to-version (was: Re: [PATCH 1/1] autoconf-archive: inherit allarch and fix package splitting)

Only during do_rootfs indeed (I don't ever do upgrades on the target using opkg).

Is there a reason to still specify prefer-arch-to-version? I'd actually expect the exact opposite compared to the original commit message's statement, unless the version numbers are identical.

Also, I would argue that the defaults during do_rootfs and when using opkg on the target should be the same...

Cheers,
Andre'

Quoted 40 lines · Martin Jansa

Is this during do_rootfs or are you seeing this issue when upgrading on the
target as well?

I haven't found the bug for this but IIRC it's because do_rootfs is using --prefer-arch-to-version parameter. meta/classes/package_ipk.bbclass:OPKG_ARGS += "--force_postinstall --prefer-arch-to-version"
which causes this undesired behavior.

Quoted 28 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

I have found previously that when changing a recipe to produce more generic
output, like in this case, and the old binary package is still in deploy/,
then the package manager would always pick the more specific version, even
if a more recent (by package version) exists in deploy. In my case I was moving from PACKAGE_ARCH=${MACHINE_ARCH} to PACKAGE_ARCH=${TUNE_PKGARCH},
but I guess it'll be the same here.

What is the correct way to deal with that other that cleansstate?

Cheers,
Andre'

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#6 lore raw
In reply to André Draszik
Quoted 6 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

Quoted 6 lines

I have found previously that when changing a recipe to produce more generic output, like in this case, and the old binary package is still in deploy/, then the package manager would always pick the more specific version, even if a more recent (by package version) exists in deploy. In my case I was moving from PACKAGE_ARCH=${MACHINE_ARCH} to PACKAGE_ARCH=${TUNE_PKGARCH}, but I guess it'll be the same here.

I think that it is because of the priority MACHINE_ARCH > TUNE_PKGARCH > allarch, which is the right behavior.

Quoted 2 lines

What is the correct way to deal with that other that cleansstate?

There is no way to fix it except cleansstate AFAIK.

// Robert

Quoted 4 lines

Cheers,
Andre'

#5 lore raw

Re: opkg --prefer-arch-to-version (was: Re: [PATCH 1/1] autoconf-archive: inherit allarch and fix package splitting)

In reply to André Draszik

I don't remember the details, but IIRC it was libdrm or something like that for some MACHINE which was providing older version of libdrm with MACHINE_ARCH with better support for that MACHINE.

So this controversial patch was implemented for opkg to support that use-case and the default behavior was changed ignoring complains from me and Koen that this behavior is wrong.

I've tried to find some e-mail threads about it, part of that discussion is in:
https://patchwork.openembedded.org/patch/37461/

Quoted 57 lines · André Draszik

Only during do_rootfs indeed (I don't ever do upgrades on the target using opkg).

Is there a reason to still specify prefer-arch-to-version? I'd actually expect the exact opposite compared to the original commit message's statement, unless the version numbers are identical.

Also, I would argue that the defaults during do_rootfs and when using opkg on the target should be the same...

Cheers,
Andre'

Quoted 4 lines · Martin Jansa

Is this during do_rootfs or are you seeing this issue when upgrading on the
target as well?

Quoted 21 lines

I haven't found the bug for this but IIRC it's because do_rootfs is using --prefer-arch-to-version parameter. meta/classes/package_ipk.bbclass:OPKG_ARGS += "--force_postinstall --prefer-arch-to-version"
which causes this undesired behavior.

Quoted 13 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

I have found previously that when changing a recipe to produce more generic
output, like in this case, and the old binary package is still in deploy/,
then the package manager would always pick the more specific version, even
if a more recent (by package version) exists in deploy. In my case I

was

Quoted 15 lines
Quoted 15 lines

moving from PACKAGE_ARCH=${MACHINE_ARCH} to
PACKAGE_ARCH=${TUNE_PKGARCH},
but I guess it'll be the same here.

What is the correct way to deal with that other that cleansstate?

Cheers,
Andre'

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#7 lore raw
In reply to Robert Yang
Quoted 19 lines · Robert Yang
Quoted 6 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

Quoted 10 lines

I have found previously that when changing a recipe to produce more generic
output, like in this case, and the old binary package is still in deploy/,
then the package manager would always pick the more specific version, even
if a more recent (by package version) exists in deploy. In my case I was moving from PACKAGE_ARCH=${MACHINE_ARCH} to PACKAGE_ARCH=${TUNE_PKGARCH},
but I guess it'll be the same here.

Quoted 3 lines

I think that it is because of the priority MACHINE_ARCH > TUNE_PKGARCH > allarch,
which is the right behavior.

I'd say this patch here is a good example why it's not the right behaviour.

This patch is making autoconf-archive allarch, i.e. lower priority than before. In other words, anybody who has the previous TUNE_PKGARCH version already will never get an update, even if the version number is bumped.

Cheers,
Andre'

#8 lore raw

But don't we remove the old version from the feeds, or does that only happen if the arch matches?

Ross

Quoted 40 lines · André Draszik
Quoted 8 lines · Robert Yang
Quoted 6 lines · André Draszik

Hi,

Quoted 2 lines · Chen Qi

autoconf-archive is a set of common m4 macros, it should be allarch, just like it is on other distros.

Quoted 7 lines
Quoted 7 lines

I have found previously that when changing a recipe to produce more generic
output, like in this case, and the old binary package is still in deploy/,
then the package manager would always pick the more specific version, even
if a more recent (by package version) exists in deploy. In my case I

was

Quoted 7 lines
Quoted 3 lines

moving from PACKAGE_ARCH=${MACHINE_ARCH} to
PACKAGE_ARCH=${TUNE_PKGARCH},
but I guess it'll be the same here.

I think that it is because of the priority MACHINE_ARCH > TUNE_PKGARCH > allarch,
which is the right behavior.

I'd say this patch here is a good example why it's not the right behaviour.

This patch is making autoconf-archive allarch, i.e. lower priority than before. In other words, anybody who has the previous TUNE_PKGARCH version already will never get an update, even if the version number is bumped.

Cheers,
Andre'

--
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.openembedded.org/mailman/listinfo/openembedded-core

#9 lore raw
Quoted 3 lines · Ross

But don't we remove the old version from the feeds, or does that only happen if the arch matches?

Well the feed pruning is working correctly:

With master from deploy/:

$ find . -name autoconf-archive*
./rpm/corei7_64/autoconf-archive-dev-2016.09.16-r0.corei7_64.rpm
./rpm/corei7_64/autoconf-archive-2016.09.16-r0.corei7_64.rpm
./rpm/corei7_64/autoconf-archive-doc-2016.09.16-r0.corei7_64.rpm
./rpm/corei7_64/autoconf-archive-dbg-2016.09.16-r0.corei7_64.rpm

With this patch applied:

$ find . -name autoconf-archive*rpm
./rpm/noarch/autoconf-archive-2016.09.16-r0.noarch.rpm
./rpm/noarch/autoconf-archive-doc-2016.09.16-r0.noarch.rpm

So, is the allarch < tune < machine logic rootfs time only, or is it used on target too? Forgive my ignorance, I haven't actually used a feed for a while.

Ross

#10 lore raw
Quoted 7 lines · Ross
Quoted 3 lines · Ross

But don't we remove the old version from the feeds, or does that only happen if the arch matches?

Well the feed pruning is working correctly:

Not for me. I created a dummy package foo_0.1.bb, with PACKAGE_ARCH = "${MACHINE_ARCH}"

after bitbake foo:

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk

Removing the PACKAGE_ARCH line from that recipe and rebuilding foo gives me:

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dbg_0.1-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dev_0.1-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo_0.1-r0_mips32r2el-24kec-nf.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk

If I bump the version, I am still left with the MACHINE_ARCH packages (doesn't matter if I bump the version before or after the change to PACKAGE_ARCH):

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dbg_0.2-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dev_0.2-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo_0.2-r0_mips32r2el-24kec-nf.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk

So of course do_rootfs will pick the outdated version.

Is that an ipk / OPKG issue? Should something be removing the old packages from deploy?

Cheers,
Andre'

#11 lore raw
Quoted 44 lines · André Draszik
Quoted 7 lines · Ross
Quoted 3 lines · Ross

But don't we remove the old version from the feeds, or does that only happen if the arch matches?

Well the feed pruning is working correctly:

Not for me. I created a dummy package foo_0.1.bb, with PACKAGE_ARCH = "${MACHINE_ARCH}"

after bitbake foo:

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk

Removing the PACKAGE_ARCH line from that recipe and rebuilding foo gives me:

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dbg_0.1-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dev_0.1-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo_0.1-r0_mips32r2el-24kec-nf.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk

If I bump the version, I am still left with the MACHINE_ARCH packages (doesn't matter if I bump the version before or after the change to PACKAGE_ARCH):

$ build.pyro > find tmp/deploy/ipk/ -name foo*ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dbg_0.2-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo-dev_0.2-r0_mips32r2el-24kec-
nf.ipk
tmp/deploy/ipk/mips32r2el-24kec-nf/f/foo/foo_0.2-r0_mips32r2el-24kec-nf.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dbg_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo-dev_0.1-r0_tgm_r3.ipk
tmp/deploy/ipk/tgm_r3/f/foo/foo_0.1-r0_tgm_r3.ipk
Quoted 4 lines

So of course do_rootfs will pick the outdated version.

Is that an ipk / OPKG issue? Should something be removing the old packages from deploy?

I tried PACKAGE_CLASSES = "package_ipk", I got the same result as ross:

* Before Qi's patch applied:

$ find tmp/deploy/ipk/ | grep autoconf-a
tmp/deploy/ipk/i586/autoconf-archive-dev_2017.09.28-r0_i586.ipk
tmp/deploy/ipk/i586/autoconf-archive_2017.09.28-r0_i586.ipk
tmp/deploy/ipk/i586/autoconf-archive-dbg_2017.09.28-r0_i586.ipk
tmp/deploy/ipk/i586/autoconf-archive-doc_2017.09.28-r0_i586.ipk

* After Qi's patch applied:

$ find tmp/deploy/ipk/ | grep autoconf-a
tmp/deploy/ipk/all/autoconf-archive_2017.09.28-r0_all.ipk
tmp/deploy/ipk/all/autoconf-archive-doc_2017.09.28-r0_all.ipk

I guess something is wrong with your build.

// Robert

Quoted 6 lines

Cheers,
Andre'

#12 lore raw

Hi,

Quoted 7 lines · Robert Yang
Quoted 3 lines · André Draszik

Is that an ipk / OPKG issue? Should something be removing the old packages
from deploy?

I tried PACKAGE_CLASSES = "package_ipk", I got the same result as ross:

OK, so I tried with autoconf-archive myself now. I get the same result as you two.

But - When moving a recipe from MACHINE_ARCH to TUNE_PKGARCH then the old package is not removed.

[...]

Quoted 1 line

I guess something is wrong with your build.

To summarise:
- moving a recipe from TUNE_PKGARCH to allarch removes the old package
- moving a recipe from MACHINE_ARCH to TUNE_PKGARCH *doesn't* remove the old package.

Where would I start looking?

Cheers,
Andre'

#13 lore raw
Quoted 18 lines · André Draszik

Hi,

Quoted 7 lines · Robert Yang
Quoted 3 lines · André Draszik

Is that an ipk / OPKG issue? Should something be removing the old packages
from deploy?

I tried PACKAGE_CLASSES = "package_ipk", I got the same result as ross:

OK, so I tried with autoconf-archive myself now. I get the same result as you two.

But - When moving a recipe from MACHINE_ARCH to TUNE_PKGARCH then the old package is not removed.

[...]

Quoted 8 lines
Quoted 1 line

I guess something is wrong with your build.

To summarise:
- moving a recipe from TUNE_PKGARCH to allarch removes the old package
- moving a recipe from MACHINE_ARCH to TUNE_PKGARCH *doesn't* remove the old package.

Where would I start looking?

It is removed by sstate.bbclass, take a look at sstate_clean() may help.

// Robert

Quoted 6 lines

Cheers,
Andre'