first off - mad props to Jeremy Katz for reminding me about 6.2 having cpan. And, yes, I'm trying to make sure this is really a bug to minimize the lart count I'm owed by Peter. NOTE: when those 2 packages are manually installed from 6.2 cpan, the infinite loop that up2date Basically, something in the up2date -u run (I'm not sure which pkgs) requires those 2 packages from cpan, but for whatever reason it can't find them to install them (i'd imagine those 2 cpan packages just need to get added to that channel, but dunno) The before-manual-install output will be attached, but it's just one big infinite loop that keeps ending with: Testing package set / solving RPM inter-dependencies... There was a package dependency problem. The message was: A package providing perl-File-Tail could not be found. A package providing perl-Date-Calc could not be found. then starts all over again, only to keep coming to the same conclusion :( After manual-cpan-pkg-install, all the relevant packages were retrieved, but up2date then just exited without applying them: Retrieving selected packages... XFree86-3.3.6-29.i386.rpm: ########################## Done. XFree86-100dpi-fonts-3.3.6- ########################## Done. XFree86-75dpi-fonts-3.3.6-2 ########################## Done. [snip] ypbind-1.7-0.6.x.i386.rpm: ########################## Done. zlib-1.1.3-25.6.i386.rpm: ########################## Done. zlib-devel-1.1.3-25.6.i386. ########################## Done. perl-Time-HiRes-01.20-6.i38 ########################## Done. [root@netsaint /root]# Subsequent up2date runs do the same thing - they just re-fetch all the packages and then up2date exits with no errors. [root@netsaint spool]# rpm -q up2date up2date-2.7.11-6.x.1
Created attachment 48427 [details] before installing those 2 cpan packages - infinite loop
Created attachment 48430 [details] after manual install from cpan - just refetches, no install
Created attachment 48432 [details] adding -v -v -v which gives very little additional information :( sep. RFE entry needed?
Well, part of the issue is that the cpan packages are not part of the channels available for 6.2. So anything that requires them is gonna bust. Not exactly sure what packages would be pulling those reqs in though. Looking though 6.2 available updates now to see if something has an invalid dep doesnt show anything. Whats: rpm -q --whatrequires perl-File-Tail perl-Date-Calc show? my guess is there is a third party package that requires those, and the perl update is causing deps to be raised. Were those packages installed before, perhaps with a dep on a specific version of perl? If thats the case, updating perl would have cause those deps to be raised, and the attempted fix would be to look for new versions of those cpan modules, which it cant find. Also, what do you mean by "infinite loop"? is the output in before-update.txt the result of just running `up2date` once? re: -v -v -v (should be a seperate request, but dont worry about it, I've already added that. -v -v -v is gonna more debug info than you ever really wanted ;->)
whoops - forgot to add that before [root@netsaint up2date]# rpm -q --whatrequires perl-File-Tail perl-Date-Calc no package requires perl-File-Tail no package requires perl-Date-Calc [root@netsaint up2date]# whatever needs them would appear to in the updates themselves. I have the updates as they're sitting in /var/spool/up2date - is there anything I can do to check them for which one of them may require it? making the -q into -qp * from the above command didn't seem to work :)
oh, and WRT "the cpan packages are not part of the channels available for 6.2", I thought the same thing until I noticed a cpan package pulled in just fine - check the attachments that are after-update, perl-Time-HiRes is pulled in fine, but I only remember perl itself being in 6.2 proper? In terms of which package requires perl-File-Tail and perl-Date-Calc, goingold school, grep would seem to indicate it's the swatch package: [root@netsaint up2date]# grep File-Tail * Binary file swatch-3.0b4-1.noarch.hdr matches Binary file swatch-3.0b4-1.noarch.rpm matches [root@netsaint up2date]# grep Date-Calc * Binary file swatch-3.0b4-1.noarch.hdr matches Binary file swatch-3.0b4-1.noarch.rpm matches and sure enough, rpm agrees: [root@netsaint up2date]# rpm -qp --requires swatch-3.0b4-1.noarch.rpm perl perl-File-Tail perl-Date-Calc perl-Time-HiRes so that also explains Time-HiRes getting pulled in so, it seems like either swatch needs to be removed from the channel or File-Tail and Date-Calc need to get added?
Also of note: #1: the only perl* package at ftp://ftp.redhat.com/pub/redhat/linux/updates/6.2/en/os/i386/ is perl itself: ncftp ...updates/6.2/en/os/i386 > ls perl* perl-5.00503-12.i386.rpm #2 the perl-Time-HiRes package that did get picked up was perl-Time-HiRes-01.20-6.i386.rpm which isn't in updates,but *was* part of the original 6.2 cpan: ftp://ftp.redhat.com/pub/redhat/linux/6.2/cpan/i386/perl-Time-HiRes-01.20-6.i386.rpm #3 Hence, it looks like at least one 6.2 cpan package (perl-Time-HiRes) got pulled into the channel, presumably to satisfy an update dependency. My guess would be that cpan packages get sucked into the channel on a needed-by basis, and File-Tail and Date-Calc just got missed when swatch and its need for them went into the channel #4 I don't see swatch in the original 6.2 os or powertools dirs, so I'm not really sure why it's in the channel at all! some errata have it obsoleting something else? At this point, I'd personally lean towards removing it from the channel, but I admit to being nowhere need familiar enough with the relevant dep graphs :)
whoops, missed this earlier: Also, what do you mean by "infinite loop"? is the output in before-update.txt the result of just running `up2date` once? **YES** - a single run that kept looping (ran *all night* in the loop, actually, since I ran the up2date -u and left). I'm not sure where the "if we couldn't satisfy deps, just start over and try again" is at, but it's definitely what I saw. want a sep bugzilla entry for it?
swatch is a noarch package in 6.2 powertools. I must of forgetten to query powertools packages for that dep as well. I wasnt really aware that 6.2 powertools had stuff that depended on 6.2-cpan, but it's definately an unsolvable dependency chain without 6.2-cpan. Ugh. Thats not supposed to happen. I'll take a look at either removing that package, or adding a 6.2-cpan channel.
re: looping okay, thats just bizarre. I dont think I've ever seen that before. /me tries to think of what could possibly cause that... uhmmm... uhmmmm... There isnt any code to fork() or exec() or anything else like that in up2date. Wonder if it could some weird userhelper issue. Would you happen to have the exact command line used? was *sbin in the path at the time? Actually, thats just weird and probabaly unrelated. A seperate bug report is probabaly a good idea.
um, nevermind on the looping thing - i just remembered that since i had to leave and I was getting the "load too high for free ppl" errors, I did a while [ $? -ne 0 ]; sleep 600; up2date -u; done ok, so only the 6.2-cpan to deal with :)
bug 61301 created for the "download but no install" thingy - just wanted to note it here
The word seems to be "no cpan channel for 6.2" (the existing one would be ancient, and building a current one isnt on anyones schedule) So, I guess that makes this a "wontfix"
well, swatch being dependant on them should've never been added then - oh, well, moving on :)