Re: Cooker upgrade still broken

On Jan 23, 2012, at 4:30 PM, [email protected] wrote:

> 
> installing urpmi-6.70-1-mdv2012.0.noarch.rpm perl-URPM-4.38-5-mdv2012.0.i586.rpm
> perl-MDV-Distribconf-4.03-4-mdv2012.0.noarch.rpm
> meta-task-2012.0-2-mdv2012.0.noarch.rpm perl-IO-Tty-1.100.0-4-mdv2012.0.i586.rpm
> aria2-1.14.1-1-mdv2012.0.i586.rpm from /var/cache/urpmi/rpms
> Installation failed:
>        rpm < 1:5.3 conflicts with perl-URPM-4.38-5.i586
>        perl-XML-LibXML < 1.890.0-3 conflicts with urpmi-6.70-1.noarch
>        perl-XML-Parser < 2.410.0-4 conflicts with urpmi-6.70-1.noarch
>        perl-Term-ReadKey < 2.30-14 conflicts with urpmi-6.70-1.noarch
>        error while checking dependencies
> 
> Installation failed:    rpm < 1:5.3 conflicts with perl-URPM-4.38-5.i586
>        perl-XML-LibXML < 1.890.0-3 conflicts with urpmi-6.70-1.noarch
>        perl-XML-Parser < 2.410.0-4 conflicts with urpmi-6.70-1.noarch
>        perl-Term-ReadKey < 2.30-14 conflicts with urpmi-6.70-1.noarch
>        error while checking dependencies
> 

Ick.

> but already run the rpm database conversion, so, effectively running
> rpm5, and it is not broken (apparently :-)
> 
> # rpm -q rpm
> rpm-4.6.0-14mnb2
> rpm-5.4.4-31
> 
> I think I can fix it, but really, should be done automatically, so,
> something to test :-)
> 

There's a couple of ways to "fix" 2010.2 that might make sense.

First of all rpm-4.6.0-1 is so munged up that I'm not
sure its worth saving.

Stealing rpm-4.8.1 or rpm-4.9.1 just has to be a better solution
than the heavily patched rpm-4.6.0. This is also pretty much
true for the MEs5 rpm-4.4.2.3 with some aggressive back ports:

The code is so heavily patched that it might be easier (going
"forward" but with the same upgrade QA matrix status quo ante)
to re-do a QA release cycle on existing packaging and attempting
an upgrade to a code base in rpm-4.8.1 or rpm-4.9.1. I'm
sure I can make either of those rpm versions "compatible"
faster than trying to understand the amount of patching
in rpm-4.6.0 (and in MES5 rpm-4.4.2.3). Not my call, just a suggestion.

The other approach would be to revert "RPM ACID" in rpm-5.3/rpm-5.4
and use a concurrent access model. There's actually a blueprint
to look at what would be involved:
	https://blueprints.launchpad.net/rpm/+spec/rpm-rpmdb-tasks
(its a note to self in Whiteboard).

Note that a conversion would still be needed if a back port were attempted
because of using secondary lookups (which is/was a huge performance win).

I expect to be forced to attempt the backport eventually even if Mandriva
chooses not to distribute, basically so I have a version of @rpm5.org
code that isn't doing 2x the I/O (because of logging) that can be
compared more objectively (see below) with rpm-4.6.0 and rpm-4.4.2.3.

(below)
rpm-5.3 -- with 2x the I/O being performed -- is already 80x faster
than rpm-4.6.0, as reported last spring. I'm just curious whether
rpm-5.3 with a concurrent model can achieve 100x the performance ;-)

Seriously: rpm-4.6.0 isn't the best version of rpm around by a lot: the flip-flop
patching done @mandriva.com because of the RPM fork is the reason. And this
older code needs to die die die no matter how that is achieved.

hth

73 de Jeff

> Paulo
>