Bug 464780

<metoo>
I have the same problem.
</metoo>

Wouldn't a release bump of avahi clear the situation up?  That is, suppose that avahi-0.6.22-11.fc9 were to be released.  Unless I'm mistaken, then when we upgraded to that EVR, *both* of the previous version-releases that are installed would be removed and replaced with *only* the new version-release.  (I.e., there would only be one installed version afterwards.)

I'm just trying to think of a solution that would be transparent to all users who haven't run into this yet.

I also suppose that going forward, someone might have to look at anaconda as well.

Lennart, next time when you re-assign something please explain why. So let me ask the 1 million dollar question then, why do you believe this is an anaconda bug, what exactly did anacando do wrong, and what should it have done instead?

I think it was me who first mentioned anaconda as a possible suspect but without saying why - sorry about that.

In our set of servers, the common factor among those who exhibited this bug was that they had been upgraded from a previous release of fedora.  The machines which had F9 installed directly didn't do this.

Also, looking for avahi entries in /var/log/yum.log* I see this:

$ sudo grep avahi /var/log/yum.log* | grep -v glib
/var/log/yum.log:Sep 30 14:57:10 Installed: avahi-autoipd-0.6.22-10.fc9.i386
/var/log/yum.log.1:Dec 12 06:52:06 Updated: avahi.i386 0.6.15-1.fc6
/var/log/yum.log.1:Apr 28 06:30:42 Updated: avahi.i386 0.6.16-4.fc6
/var/log/yum.log.2:May 22 06:40:28 Updated: avahi.i386 0.6.9-9.FC5
/var/log/yum.log.2:Jun 13 04:54:54 Updated: avahi.i386 0.6.10-1.FC5
/var/log/yum.log.2:Nov 29 04:41:45 Updated: avahi.i386 0.6.11-2.fc5
/var/log/yum.log-20080114:Dec 29 06:37:38 Updated: avahi - 0.6.21-8.fc8.i386
/var/log/yum.log-20080114:Dec 29 06:37:39 Updated: avahi-compat-libdns_sd - 0.6.21-8.fc8.i386
/var/log/yum.log.3:Apr 12 09:33:53 Updated: avahi.i386 0.6.9-8.FC5

Neither of the offending duplicated packages are shown which I think means that they were installed via anaconda (all our updates are through yum so I'm pretty sure that nothing was done directly through rpm).

I don't know if this is a packaging problem or an update problem but I suspect anaconda is involved somewhere along the line.  It may well be that this has been lying dormant since FC7 and is only now manifesting itself.

I have the same problem, and I tried to resolve it by saying 

    yum remove avahi-0.6.16-4.fc6.i386

and yum claimed to have removed it, but really didn't.  So there's a yum problem to be resolved, I think.

I'm seeing this same issue.  My system was upgraded from Fedora 8 with "preupgrade", and similarly from Fedora 7.

Doing "rpm -q avahi" I see

avahi-0.6.17-1.fc7.i386
avahi-0.6.22-10.fc9.i386

so there's an old avahi around.  Great, I said, I'll try

rpm -e avahi-0.6.17-1.fc7.i386

but I then get

error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1

So I read the man page and then tried

rpm -e --nopostun avahi-0.6.17-1.fc7.i386

That cleaned up the mess, and yum update then succeeded in installing avahi-autoipd and upgrading NetworkManager.

Brian @ #4, it looks like using yum instead of rpm directly hides the error.  If so, that could be considered a yum bug.

(In reply to comment #5)
> I'm seeing this same issue.  My system was upgraded from Fedora 8 with
> "preupgrade", and similarly from Fedora 7.
> 
> Doing "rpm -q avahi" I see
> 
> avahi-0.6.17-1.fc7.i386
> avahi-0.6.22-10.fc9.i386
> 
> so there's an old avahi around.  Great, I said, I'll try
> 
> rpm -e avahi-0.6.17-1.fc7.i386
> 
> but I then get
> 
> error: %postun(avahi-0.6.17-1.fc7.i386) scriptlet failed, exit status 1
> 
> So I read the man page and then tried
> 
> rpm -e --nopostun avahi-0.6.17-1.fc7.i386
> 
> That cleaned up the mess, and yum update then succeeded in installing
> avahi-autoipd and upgrading NetworkManager.
> 

Thanks for this info! This explains the problem and also makes it an ahavi package problem post scripts should be written in such a way that they never fail!

Unfortunately we cannot retraactively fix the fc7 package, so I'm closing this as cantfix :(

I will file a bug against yum to add an option to ignore rpmpost script errors and erase the package anyways.

yum bug 465409

I'm still not quite clear about this.

If the scriptlet failed then how did the upgrade to the new version succeed leaving two versions installed?  Should the whole transaction not have failed and been rewound?  Is this something to do with the more brute force approach taken by anaconda when doing updates (where I believe it ignores errors which would otherwise cause a transaction to abort).

I'm just wondering if there's any way to stop this from happening again at a yum / rpm / anaconda level?

An rpm update roughly works like this (non relevant steps left out):

1) install new version
2) run %post install script of new version
3) enter new version into rpmdb
4) uninstall old version (not removng any files replaced by 1)
5) run %postun script of old version
6) remove old version from rpmdb

As 5 fails 6 is never done, this is really a packaging bug and the problem is its a packaging bug of the old package which thus cannot be fixed after a package is released. There are plans to change rpm to make bugs like these have less consequences, see bug 465409

I hope this helps.