Libarchive package name change and OPKG upgrade from ipk?

We use colibri vf50 board running with Linux and our device has to be remotely completely upgrade-able. This we solved and for upgrade we use opkg and ipk files generated by bitbake.

After upgrade from Toradex version 2.6.1 to version 2.7 we found out that package name of libarchive has changed from “libarchive13” to “libarchive”
and opkg than refuses upgrade of this library since:

opkg install libarchive_3.2.2-r0_armv7at2hf-neon.ipk
Installing libarchive (3.2.2-r0) on root.
To remove package debris, try `opkg remove libarchive`.
To re-attempt the install, try `opkg install libarchive`.

Collected errors:
 * check_data_file_clashes: Package libarchive wants to install file /usr/lib/
        But that file is already provided by package  * libarchive13
 * opkg_install_cmd: Cannot install package libarchive.*

In case that we use opkg install --force-overwrite libarchive_3.2.2-r0_armv7at2hf-neon.ipk the library is installed, but opkg installs it as separate package,
i.e /var/lib/opkg/status file contains record for both packages:

Package: libarchive
Version: 3.2.2-r0
Depends: libbz2-1 (>= 1.0.6), libc6 (>= 2.24), libxml2 (>= 2.9.4), libz1 (>= 1.2.8)
Status: install user installed
Architecture: armv7at2hf-neon
Installed-Time: 1506672018

Package: libarchive13
Version: 3.1.2-r0
Depends: libxml2 (>= 2.9.2), libz1 (>= 1.2.8), libc6 (>= 2.22), libbz2-0 (>= 1.0.6), libattr1 (>= 2.4.47)
Provides: libarchive
Status: install ok installed
Architecture: armv7at2hf-vfp-neon
Installed-Time: 1505730908

And it seems that opkg still try to use previous version 3.1.2-r0 that is wrong.

Another problem we have is that after upgrade of libopkg1 from 1:0.3.0-r0 to 1:0.3.3-r0, the opkg starts crashing.

I’m not sure, but I guess that this way of upgrading opkgs and its libraries isn’t proper.

Could you advice me how to upgrade opkg and its components ( libarchive, libopkg1, update-alternatives-opkg ) by using its ipk files?

Thank you.

Generally, Toradex as well as OpenEmbedded/Angstrom do not support/test using upgrade path of the package manager… That said, if you have a sufficient small amount of packages you need to support/upgrade it might be a worthwhile upgrade strategy.

It seems that jethro (V2.6.1) also put the libtool interface version into the package name (13). This seems to be the case when the recipe inherits lib_package, which got removed by this change. I would guess when you readd it to the morty recipe of libarchive, it would produce a package with the name libarchive13 again which might solve the problem.

Another solution might be to add a RCONFLICT variable to the recipe to make sure that libarchive conflicts with libarchive13.

Regarding libopkg1, I would guess that when you upgrade the libraries and opkg in a single command, it should make sure that a consistent state will be on flash after the upgrade.