Hm, how is that possible ?

perl-URPM & urpmi are priority packages that should get installed in the first transaction, then restarting the upgrade with new urpmi&co for the rest...

CC: (none) => tmb

Those packages are installed by the Mageia 5 version of perl-URPM, after it has
found the priority updates and reported the conflict in the two Mageia 6
versions of the task-obsolete package.

After perl-URPM is installed, and restarted, the task-obsolete package does
install cleanly, as do all of the rest of the updates.

Note that this is a very cosmetic issue and has no impact on the upgrade,
except that it will scare people, who may choose to abort the upgrade
instead of selecting the continue option.

Ah, of course... it parses all rpms before doing the prio update... /me needs a new head...

@Thierry, do you think we should push an update for this in mga5 too ?

Assignee: bugsquad => thierry.vignaud

This can lead to many more conflicts being reported. See comment 67 on bug 23037 and attachment 10246 [details].

These conflicts are being reported after the priority updates have been installed. This is the process that is running when the pop-up appears:

/usr/bin/perl /usr/libexec/gurpmi2 --previous-priority-upgrade=rpm,perl-URPM,perl-MDV-Distribconf,urpmi,meta-task,glibc,aria2,gurpmi,perl-Glib,perl-Glib-Object-Introspection,perl-Gtk3 --auto --auto-select --replacefiles --clean

Applying the fix to the mga5 version of perl-URPM before starting the upgrade helper does not fix the problem.

As Dave notes, if you choose to continue, the correct updates are eventually installed. This is because the upgrade helper reruns gurpmi up to 4 times, and once the old version of task-obsolete has been installed, it gets updated on the next run.

CC: (none) => mageia

Reproducible using my previously saved urpmi database (bug 23037 comment 47):

# rpm -qa | grep perl-URPM
perl-URPM-5.12.1-1.mga6
# urpmi.removemedia --urpmi-root R -a
...
# urpmi.addmedia --urpmi-root R --distrib ftp://ftp.mirrorservice.org/pub/mageia/distrib/6/x86_64
...
# urpmi --urpmi-root R --justdb --auto-select --auto 2>&1| tee upgrade.log     
Some requested packages cannot be installed:
kdeplasma-addons-5.12.2-1.mga6.x86_64 (due to conflicts with kdeplasma-addons-5.8.7-1.mga6.x86_64)
task-obsolete-6-128.3.mga6.noarch (due to conflicts with task-obsolete-6-128.mga6.noarch)
...

Investigating further, task-obsolete-6-128.mga6.noarch is being selected because

auto-select: prefering task-obsolete-6-128.mga6.noarch obsoleting kde-l10n-en_GB-4.14.3-1.mga5.noarch over kde-l10n-en_GB-16.12.3-2.mga6.noarch

auto-select: prefering task-obsolete-6-128.mga6.noarch obsoleting kde-l10n-handbooks-en_GB-4.14.3-1.mga5.noarch over kde-l10n-handbooks-en_GB-16.12.3-2.mga6.noarch

because Thierry removed kde-l10n-* in task-obsolete-128.3.mga6.noarch. What package is supposed to be obsoleting kde-l10n-* now? (sadly urpmq doesn't have a --whatobsoletes option).

CC: (none) => mageia

1) that was explained in bug 23037

2) urpmf --obsoletes is your friend
# urpmf  --urpmi-root R --obsoletes kde-l10n-en
kde-l10n-handbooks-en_GB:kde-l10n-en_GB-handbooks[< 4.8.0-2]
task-obsolete:kde-l10n-en_GB[< 17.12.0-1]
task-obsolete:kde-l10n-en_US[< 17.12.0-1]

I might have been too fast and got mixed up by kde-l10n-handbooks-* obsoletes

3) kde-l10n-* got removed due to conflicts anyway

(In reply to Thierry Vignaud from comment #8)
> 1) that was explained in bug 23037

Not really. You said you were removing double obsoletes from task-obsolete, but you didn't say where the doubles were, which was my question.

Reverting the changes in task-obsolete-128.3 (including kde-l10n-handbooks) fixes this bug for me. I still need to test a net install to make sure it has no adverse effect there.

Nicolas still needs to fix kdeplasma-addons to give us a clean upgrade.

Net install is OK, after updating stage2 with the reverted task-obsolete and updating rpmsrate.

Looking at kdeplasma-addons, the main problem is that an older version has

 Obsoletes:  plasma-runner-audioplayercontrol < 4.14.3-5
 Provides:   plasma-runner-audioplayercontrol = %version-%release

but the latest version does not, so the old version is being selected to replace plasma-runner-audioplayercontrol.

More importantly, I still occasionally see the major failure reported in bug 23037 comment 67. The root cause of the failure is

chosen attica-5.42.0-1.mga6.x86_64 for attica[== 5.42.0-1.mga6]
selecting attica-5.42.0-1.mga6.x86_64
installed package kde-l10n-en_GB-4.14.3-1.mga5.noarch is conflicting with attica-5.42.0-1.mga6.x86_64 (Conflicts: kde-l10n[< 15.04.0])
promoting kde-l10n-en_GB-16.12.3-2.mga6.noarch|kde-l10n-en_GB-16.12.3-2.mga6.noarch because of conflict above
chosen kde-l10n-en_GB-16.12.3-2.mga6.noarch for kde-l10n-en_GB|kde-l10n-en_GB
selecting kde-l10n-en_GB-16.12.3-2.mga6.noarch

Once the obsolete kde-l10n-en_GB-16.12.3-2.mga6.noarch has been selected, it has a cascade effect, leading to what's seen in attachment 10246 [details].

Without fixing urpmi to not select obsoleted packages, I don't know how to reliably fix this.

Note that these failures don't occur every time, as urpmi processes the package list and resolves dependencies in an essentially random order. Sometimes you get lucky, sometimes you don't.

Created attachment 10249 [details]
Debug output from urpmi when major failure occurred

I've updated task-obsolete to restore the obsoletes for the kde-l10n packages. I've split the other issues out into separate bugs.

Advisory
========
The previous change to task-obsolete has been reverted, as the kde-l10n packages do need to be obsoleted (mga#23202)

RPMs
====
task-obsolete-6-128.4.mga6.src.rpm
task-obsolete-6-128.4.mga6.noarch.rpm

Testing
=======
All you can really do is test the new version installs and doesn't cause anything else to be removed. Verifying it fixes the upgrade bug can only be done once this update is moved to core/updates.

Assignee: thierry.vignaud => qa-bugs

Mga6 update set to mga5. 

Also duplicated, which now seems better handled with perl-URPM in bug 23229.

Assigning back to Martin

Assignee: qa-bugs => mageia

Today's upgrade test under vb completed with no errors.

Closing as fixed. Thanks everyone.

Status: NEW => RESOLVED
Resolution: (none) => FIXED

confirming fixed  with i586 upgrade on real hardware.

3000 + packages (approx 80 min)

only issue of note was at reboot flashing cursor presented after selecting Mga6 from grub menu.
power down and boot up - ok

confirming fixed  with x86_64 upgrade on real hardware.

3000 + packages

no issues noted after boot up to desktop