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 :-)

  After "rpm -e --nodeps --justdb rpm-4.6.0-14mnb2" and some perl
modules that had a 2010.1 and a 2012.0 version installed, I did
"rpm -e --nodeps --justdb" every *drak*2010.1* package, and then
it was the time of *webkit*2010.1*.
  Oh, before that, I needed to update initscripts manually, then
remove/update a few other packages to switch to systemd.

  Now it appears to be on its way to convert a 2010.2 to cooker...

  What is required is somebody to work on these kinds of updates
frequently, and correct any issues that may arise. Manually I can
fix it, and rpm/urpmi has enough machinery to allow it to be done
automatically.

> 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