On Tue, Jul 18, 2006 at 09:22:57AM -0400, Michael H. Warfield wrote: > On Tue, 2006-07-18 at 10:41 +0200, Axel Thimm wrote: > > The issues are with upgrading within a kernel and coinstalling for > > different kernels. If you merge the two different versions then the > > system can never know whether the packages are to be coinstalled or > > replaced and upgraded. *Both* operations are required. ATrpms solves > > this by requiring one to be done manually. If you merge the versions > > you either sacrifice upgrades within a kernel line or supporting > > concurrently installed kernels. > > Which is exactly what I think I saw with the recent Zaptel release and > the conflicts between the kmdl zaptel modules for the 2145 and 2157 > kernels. They can't coexexist because of the conflicting requirements > for zaptel and it requires manual intervention to clean it up. Well, you did sent me a bug report in private which showed that your system had several rpm inconsistencies like asterisk not finding spansp libs although the packaging dependencies are in place, and since you didn't reply to my diagnosis I can only assume that it's a local problem on your system. kmdls are in the field for several years and their "drawback" is that they don't interact cross-kernel wise, so it's unlikely that installing zaptel-kmdl for a new kernel would be blocked by the old kmdls. There is (was) something else amiss on your system. zaptel packages are also very well consumed, so if it really were an issue it would bring in a second report by now. > > > (I'm looking at most of what it wanted to update and I'm coming to the > > > conclusion that ATrpms and Livna have never learned to play nicey nicey > > > in the same sandbox). > > > I think this conclusion is wrong. In your example above there isn't > > any ATrpms package. Also livna and ATrpms are at good terms, even > > though incompatibilites between different repos may always arise. But > > even here the maintainers are thinking of better solutions. Still the > > above example has no ATrpms in it, so it is not from the > > incompatibilities category. > > Ok... I didn't want to post the "full" example because it's pretty > big. So, I freshened things up a bit to make sure all packages are > correctly up to date and reran. Forgive the length. > [... very big output ...] > > > I've been in dependency hell too often after making that mistake and > > > the above is an illustration why. > > > You should perhaps try using smart instead of yum. At the very least > > it will not bail out and you will get a better understanding of which > > package was trying to block the upgrade process. > > I'll give smart a look. Please give that first a try before we diagnose a possible yum failure over several mails focusing on the wrong bits. Also have a check on your rpm database. the zaptel and asterisk to spandsp dependencies seem to have failed on your system, if the rpm database is corrupted we may be hunting ghosts. rpm -V package is your friend and rpm --rebuilddb will try to fix the database, but corner the issue first to that by for instance hunting down the asterisk/spandsp/ldd issue. -- Axel.Thimm at ATrpms.net
Attachment:
pgplh690ZOh8w.pgp
Description: PGP signature
