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