Ticket #2109 (in_testing defect)

Opened 8 years ago

Last modified 8 years ago

Upgrade path error from Om2008.9 to testing

Reported by: john_lee Owned by: tick
Priority: high Milestone:
Component: Distro Version: Om2008.9-dev
Severity: normal Keywords: Om2008.11
Cc: testing@… Blocked By:
Blocking: Estimated Completion (week):
HasPatchForReview: no PatchReviewResult:
Reproducible: always

Description

Since we're going to do the next release from the om.dev branch, the problems on the upgrade path from Om2008.9 to the current testing repo (build from om.dev) must be fixed.

Currently I have noticed the following:

 * Package dbus-x11 wants to install file /usr/bin/dbus-launch
	But that file is already provided by package  * dbus-1
 * Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0
	But that file is already provided by package  * libglib-2.0-0
 * Package ncurses wants to install file /usr/lib/libncurses.so.5
	But that file is already provided by package  * libncurses5

Not sure about the rest, but I know dbus-x11 is set to conflict/replace the original dbus-1. The preferred action of opkg is to automatically replace dbus-1 by dbus-x11, but it's not the case at the moment. We need to figure out where to fix this (in opkg or in OE) and provide a clean upgrade path.

Change History

comment:1 Changed 8 years ago by tick

  • Status changed from new to accepted

comment:2 Changed 8 years ago by tick

I tried to upgrade libgobject-2.0-0 directly and get
Collected errors:

  • Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0.1600.1

But that file is already provided by package * libglib-2.0-0

  • Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0

But that file is already provided by package * libglib-2.0-0

I tried this and passed.

root@om-gta02:/var/lib/opkg# opkg install libglib-2.0-0
Upgrading libglib-2.0-0 on root from 2.16.1-r4 to 2.16.1-r5...
Downloading http://192.168.0.200/build/deploy/glibc/opk/armv4t//libglib-2.0-0_2.16.1-r5_armv4t.opk
Configuring libglib-2.0-0
root@om-gta02:/var/lib/opkg# opkg install libgobject

root@om-gta02:/var/lib/opkg# opkg install libgobject-2.0-0
Installing libgobject-2.0-0 (2.16.1-r5) to root...
Downloading http://192.168.0.200/build/deploy/glibc/opk/armv4t//libgobject-2.0-0_2.16.1-r5_armv4t.opk
Configuring libgobject-2.0-0

In /var/lib/opkg/oe-armv4t I got
Package: libgobject-2.0-0
Version: 2.16.1-r5
Depends: libglib-2.0-0 (>= 2.16.1), libc6 (>= 2.6.1)
Section: libs
Architecture: armv4t
Maintainer: Angstrom Developers <angstrom-distro-devel@…>
MD5Sum: fd7905f71886a4fe13e0ffc1aeb3e17b
Size: 65848
Filename: libgobject-2.0-0_2.16.1-r5_armv4t.opk
Source: http://ftp.gnome.org/pub/GNOME/sources/glib/2.16/glib-2.16.1.tar.bz2 file://glibconfig-sysdefs.h file:/
Description: GLib is a general-purpose utility library, which provides many useful data types, macros, type con
OE: glib-2.0
HomePage?: unknown
Priority: optional

That means opkg only knows libglib-2.0-0 (>= 2.16.1) while upgrading libgobject-2.0-0 and libglib-2.0-0 is indeed >= 2.16.1
Therefore, opkg will not know it should upgrade libglib first.

In order to solve this, I think the dependency should also consider PE and PR.

Will this cause any side effect? Pondering....

comment:3 Changed 8 years ago by tick

In this case OE moves /usr/lib/libgobject-2.0.so.0.1600.1 from libglib-2.0-0 to libgobject-2.0-0 and adding PR for libglib-2.0-0
to 5.

In this case libgobject is depends on libglib-2.0-0_2.16.1-r5 and after.

There are two ways to solve this issue.

  1. Let libgobject-2.0-0 depends on libglib-2.0-0 (>= 2.16.1-r5) modify this on OE.
  2. Let opkg to check if libglib-2.0-0 should upgrade or not. If yes then upgrade it first. This may introduce infinite loop if there are any two packages depends on each other and adding PR at the same time.

In my option, this issues happens because the metadata is wrong, and so that opkg does not know upgrade order.

comment:4 follow-up: ↓ 6 Changed 8 years ago by tick

In ncurses it will be another story.
opkg should check if libncurses5 is installed or not first.
If so remove it first.

Package: ncurses
Version: 5.4-r15
Depends: libc6 (>= 2.6.1)
Provides: libncurses5
Suggests: ncurses-terminfo
Section: libs
Architecture: armv4t
Maintainer: Angstrom Developers <angstrom-distro-devel@…>
MD5Sum: 54e1f270fb60695a7b4fb6cbb689254c
Size: 168540
Filename: ncurses_5.4-r15_armv4t.opk
Source: ftp://ftp.gnu.org/gnu/ncurses/ncurses-5.4.tar.gz file://makefile_tweak.patch;patch=1 file://visibility.
Description: Ncurses library
OE: ncurses
HomePage?: http://www.gnu.org/software/ncurses/ncurses.html
Priority: optional

comment:5 Changed 8 years ago by tick

dbus-x11 should provides dbus-1, this should be defined on OE

comment:6 in reply to: ↑ 4 Changed 8 years ago by tick

Replying to tick:

In ncurses it will be another story.
opkg should check if libncurses5 is installed or not first.
If so remove it first.

http://www.debian.org/doc/FAQ/ch-pkg_basics.en.html#s-depends

Hmmm... Maybe opkg should not remove libncurses5 first.

comment:8 follow-up: ↓ 9 Changed 8 years ago by tick

Therefore ncurses should
Provides: libncurses5
Replaces: libncurses5
Conflicts: libncurses5

comment:9 in reply to: ↑ 8 Changed 8 years ago by tick

Replying to tick:

Therefore ncurses should
Provides: libncurses5
Replaces: libncurses5
Conflicts: libncurses5

If I set so
root@om-gta02:~# opkg upgrade ncurses
Upgrading ncurses on root from 5.4-r14 to 5.4-r15...
Seems I've found a replace libncurses5 libncurses5
Downloading http://192.168.0.200/build/deploy/glibc/opk/armv4t//ncurses_5.4-r15_armv4t.opk
Removing package libncurses5 from root...
Configuring ncurses
root@om-gta02:~#

Therefore, this issue should be solved in OE bb files.

comment:10 Changed 8 years ago by tick

  • Component changed from opkg to Distro

comment:11 Changed 8 years ago by tick

org.openmoko.dev:
608273b69f736830047013f68b763792af500251
88fcd320b2f0954b52a90889880db0a29a70373b
solves the dbus-1 & ncurses problem

libgobject is depended on libglib-2.0 ( >= 2.16.1-r5 )
However this is depended on PR not source code.
I do not sure how to do it right now.
Any suggestion?

comment:12 Changed 8 years ago by tick

update the libglib to 2.18.1 and that can make sure libglib-2.0 will be update first.
om.dev: 27267ec80a4dbeb9bdfbff39c2ff3ee92bdac2ec

Thought it does not solve my problem directly, this kind of change should be made from version to version originally not by PR.

also solve virtual package issues of xserver-kdrive
om.dev: 2652c7b0ebc4d839a569fbd2f6c3493760390913

comment:13 Changed 8 years ago by tick

Okay... I can upgrade from Om2008.9 to my own latest daily build now.

As long as people modify the packages info wrongly, this issue will happen again and again.

My suggestion everyone wants to move something from one package to another should read this first:
http://www.debian.org/doc/debian-policy/ch-relationships.html#s-virtual

comment:14 Changed 8 years ago by john_lee

  • Keywords Om2008.11 added

comment:15 Changed 8 years ago by john_lee

  • Status changed from accepted to in_testing
  • Cc testing@… added

please test if there are more issues like this. if not, please close this ticket.

comment:16 follow-up: ↓ 18 Changed 8 years ago by john_lee

Tested upgrade from Om2008.9 to current testing repo and got the following:

  • Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0

But that file is already provided by package * libglib-2.0-0

  • Package libgmodule-2.0-0 wants to install file /usr/lib/libgmodule-2.0.so.0

But that file is already provided by package * libglib-2.0-0

  • Package xserver-security-policy wants to install file /usr/lib/xserver/SecurityPolicy

But that file is already provided by package * xserver-kdrive

  • ERROR: avahi-daemon.postinst returned 1

Actually tick's update to glib does work, but somehow opkg is still confused:

root@om-gta02:~# opkg info libglib-2.0-0
Package: libglib-2.0-0
Version: 2.18.1-r0
Depends: libgcc1 (>= 4.1.2), libc6 (>= 2.6.1)
Status: install user installed
Architecture: armv4t
Installed-Time: 1227199733

root@om-gta02:~# opkg files libglib-2.0-0
Package libglib-2.0-0 (2.18.1-r0) is installed on root and has the following files:
/usr/lib/libglib-2.0.so.0.1800.1
/usr/lib/libglib-2.0.so.0

comment:17 Changed 8 years ago by john_lee

also I lost all-feed.conf, armv4t-feed.conf and om-gta02-feed.conf under /etc/opkg after I chose 'Y' use the maintainer's version in distro-feed-configs during upgrade... this is bad.

btw, Illume packages are broken. Still need to modify the RPROVIDE, RCONFLICT and RREPLACE...

comment:18 in reply to: ↑ 16 Changed 8 years ago by john_lee

Replying to john_lee:

Tested upgrade from Om2008.9 to current testing repo and got the following:

  • Package libgobject-2.0-0 wants to install file /usr/lib/libgobject-2.0.so.0

(snipped)

Tick confirmed that this is the expected behavior and opkg can still finish the upgrade process, so this is not a bug. Now I just need to take care of the illume and distro-feed-configs problems.

comment:19 Changed 8 years ago by john_lee

The /etc/opkg/*.cfg disappearing issue never happens again. Commit 081bd0a65f976b2899ad3265f707b855bd6436b4 fixed the illume upgrade path, but the config file shipped with Om2008.9 is still wrong, so I have to cook a postinst script to fix that.

comment:20 Changed 8 years ago by john_lee

avahi problem fixed. illume cfg problem fixed. holger reminds me the kernel modules won't get cleanly replaced and he is right. need to work on that as well.

comment:21 Changed 8 years ago by john_lee

another issue: distro-feed-configs must be able to replace openmoko-feed-configs and remove the unnecessary neo1973 conf.

comment:22 Changed 8 years ago by tick

After testing upgrading from Om2008.9 to testing, the repository upgrade path is in a good shape now. With opkg svn 4838. I can do upgrading in 25 mins, where the repository is in nearby network. That is much faster than before.

However, I found another issue, that we may need to upgrade twice to get all packages upgraded. I believe it's a bug in opkg dependency calculation. I will file another ticket to describe this issue. This issue also happens in older version of opkg. Still need to dig in.

For this ticket, I think in OE it's good now.

Note: See TracTickets for help on using tickets.