apt lorg3 on RH9

Panu Matilainen pmatilai at laiskiainen.org
Wed Apr 26 22:36:24 PDT 2006


On Thu, 2006-04-27 at 01:23 +0200, Dag Wieers wrote:
> On Tue, 25 Apr 2006, Panu Matilainen wrote:
> 
> > On Tue, 2006-04-25 at 15:31 +0200, Dag Wieers wrote:
> >
> > > This seems to be epoch related, however it doesn't concern an undefined 
> > > epoch afaics. This is what is installed:
> > 
> > Sigh. Oh well, I certainly did expect epoch breakage on older RH's. The
> > repomd data is fedora.us all over again: it stomps zero epochs on every
> > package, versioned dependency and provides regardless if the epoch
> > actually is defined as zero or doesn't exist.
> > 
> > Apt treats zero epochs in package versions from repomd as non-existing
> > to try to deal with this but it's obviously not enough, provides and
> > dependencies need to be dealt with as well. Can you try if the attached
> > patch fixes it (do "rm -f /var/cache/apt/*.bin" first)? This treats zero
> > epoch from repomd as nonexistent on dependencies as provides as well,
> > which I think should trigger the promoteepoch behavior. Hopefully. I've
> > been trying hard to forget about the epoch mess of the old days :)
> 
> I now see this after doing the patch:
> 
> 	You might want to run `apt-get --fix-broken install' to correct these.
> 	The following packages have unmet dependencies:
> 	  perl: Depends: perl (>= 5.007003)
> 	        Depends: perl (>= 5.00503)
> 	  perl-DateManip: Depends: perl (>= 5.00503)
> 	  perl-HTML-Tagset: Depends: perl (>= 5.00503)
> 	  perl-Parse-Yapp: Depends: perl (>= 5.00503)
> 	  perl-Time-HiRes: Depends: perl (>= 5.00503)
> 	  perl-TimeDate: Depends: perl (>= 5.00503)
> 	  perl-URI: Depends: perl (>= 5.00503)
> 	  perl-libwww-perl: Depends: perl (>= 5.00503)
> 	  perl-libxml-enno: Depends: perl (>= 5.00503)
> 	  rpm-build: Depends: perl (>= 5.006001)
> 	E: Unmet dependencies. Try using --fix-broken.

Uh, something else is unhappy now :-/

> 
> It concerns the following packages:
> 
> 	[root at rh9i /]# rpm -q --qf "%{name} %{epoch}:%{version}-%{release}\n" perl perl-DateManip perl-HTML-Tagset perl-Parse-Yapp perl-Time-HiRes perl-TimeDate perl-URI perl-libwww-perl perl-libxml-enno rpm-build
> 	perl 2:5.8.0-90.0.13.legacy
> 	perl-DateManip (none):5.40-30
> 	perl-HTML-Tagset (none):3.03-28
> 	perl-Parse-Yapp (none):1.05-30
> 	perl-Time-HiRes (none):1.38-3
> 	perl-TimeDate (none):1.1301-5
> 	perl-URI (none):1.21-7
> 	perl-libwww-perl (none):5.65-6
> 	perl-libxml-enno (none):1.02-29
> 	rpm-build (none):4.2-0.69
> 
> This probably is because perl 5.8.0 is considered 'older' than 5.00503 or 
> 5.007003 and the epoch is disregarded ?

A wild wild guess but these packages seem to actually have the epoch in
their requires originally:
[pmatilai at weasel ~]$ rpm -qp --requires perl-URI-1.21-7.noarch.rpm
perl >= 0:5.00503
[pmatilai at weasel ~]$ rpm -qp --requires rpm-build-4.2-0.69.i386.rpm
perl >= 0:5.006001

..which now gets stripped out and it's not supposed to matter but
something obviously *does* care. 

<scratches head>

Then there's the issue of those packages with real epoch zero in them
showing up as different packages in rpmdb vs repository because rpmdb
handling doesn't strip out the zero epoch.. oh madness.

> Why did the previous apt handle it correctly ?

Could you check if the new apt handles this correctly if you're using
old apt metadata instead of repomd? That should help pinning it down -
there shouldn't be any changes from previous versions with old metadata
but ... the repomd changes shuffled around quite a bit of rpm handling
code.

> 
> So many questions ?

So few answers :( If it comes to that, I'll install RHL 9 on my testbox
and see for myself but I'd really rather not have that trip down the
memory lane :D

	- Panu -





More information about the Apt-Rpm mailing list