rsync 3.10 now defaults to human readable output, with sizes being
printed with a separator between group of 3 digits.
This broke our download progress parser.

We can fix this by using the --no-human-readable command line option,
to get the old rsync progress output format.

This option already existed in older rsync versions (tried in Mageia
2), so this change should be safe to include in backports of urpmi to
older distributions.

(translate_why_removed_one) ensure we got the right reason

(testsuite) adapt to new URPM predictible behaviour

it was previously relying on the following fixed hash order:

$ perl -MData::Dumper -e 'warn Dumper [ keys {'rr1', 'rr1', 'rr2',
'rr2'} ]; \
warn Dumper [ keys {'bb1', 'bb1', 'bb2', 'bb2-1'} ]'
$VAR1 = [
          'rr2',
          'rr1'
        ];
$VAR1 = [
          'bb1',
          'bb2'
        ];

(eg: running testsuite in a chroot)

the bug was actually in media.cfg

basically reverting commit r8361 on 2013-05-24 (was: "fix wrongly
enabling backports/testing for tainted/nonfree (mga#10254)")

(when such packages are already installed)

This fix is needed in cases where rpm's libdb changes. If the priority updates
happen to be installed in more than one transaction, the %post script in rpm
which deletes the old index files (/var/lib/rpm/__db.*) may happen at the
end of the first of those transactions. This causes the indexes to be
regenerated by the *old* db version and causes the second transaction to fail.

By ensuring the priority updates are handled in a single transaction, the
indexes will be recreated after the urpmi restart and will thus use the
correct, new libdb to create the indexes.

Patch and fix from Thierry Vignaud