When NSS is busted then yes, rpm will be very very ill no matter which version. Whether this is due to an rpm bug or something else like remains to be seen.

What did "today's rawhide update" include exactly? Please copy-paste/attach the relevant part of /var/log/yum.log.

FWIW, 'rpm --nosignature --nodigest' might be enough to allow reinstalling the broken nss packages. If not, using rpm2cpio (or as that might fail here too, /usr/lib/rpm/rpm2cpio.sh) to install the broken packages ought to allow getting it back to a functional state.

But more importantly, we need to understand what exactly happened here and how.
Symlinks being involved makes me wonder... rpm doesn't go inventing symlinks out of the blue, and rawhide nss doesn't have any symlinks, hasn't had for a while. Was "todays rawhide update" something like f16 -> rawhide upgrade, involving /usrmove and all? Please provide full details of the steps that lead to this situation.

Created attachment 574410 [details]
yum log

Yum log from  rawhide upgrade on Mar. 31

Created attachment 574411 [details]
rpm --nodigest --nosignature -qa

list of packages 

Without --nodigest --nosignature - I get just tons of:

error: rpmdbNextIterator: skipping h#   25333 Verify signature: BAD PARAMETERS (269 0xb29390 1 (nil) (nil))

Without only --nosignature:

I'm getting mixed listing:

nss-mdns-0.10-10.fc17.x86_64
rpm-4.9.90-0.git11505.7.fc18.x86_64
error: rpmdbNextIterator: skipping h#   30143 Verify signature: BAD PARAMETERS (268 0x259da10 536 (nil) 0x25a9d60)
pinfo-0.6.10-4.fc17.x86_64

So to fix the system from this:

Download nss-softokn-3.13.3-2.fc18 packages - and replaces those from  fc16 update via:

rpm --nodigest --nofiledigest --replacefiles -Uvh nss-softokn*rpm


This seems to fix rpm usability issue.
rpm needs to watch for linking between /lib and /usr/lib after usermove
since updated 'newer' package for fc16 got installed over fc18 version.

Thanks Panu with quick help to resolve this.

So... the issue is installing /usrmove affected package from f16 on a system
where /usrmove conversion has been done:

Mar 31 14:14:33 Updated: nss-softokn-freebl-3.13.3-2.1.fc16.x86_64

In the f16 versions, nss (and various other) packages have symlinks from
/usr/lib(64) to /lib(64):

[root@localhost ~]# ls -l /lib64/*freebl*
-rw-r--r--. 1 root root    478 Mar 10 23:04 /lib64/libfreebl3.chk
-rwxr-xr-x. 1 root root 390288 Mar 10 23:04 /lib64/libfreebl3.so
[root@localhost ~]# ls -l /usr/lib64/*freebl*
lrwxrwxrwx. 1 root root    26 Mar 19 12:24 /usr/lib64/libfreebl3.chk ->
../../lib64/libfreebl3.chk
lrwxrwxrwx. 1 root root    25 Mar 19 12:24 /usr/lib64/libfreebl3.so ->
../../lib64/libfreebl3.so
-rw-r--r--. 1 root root 55154 Mar 10 23:04 /usr/lib64/libfreebl.a

...and when /lib(64) is symlinked to /usr/lib(64), the package ends up having a
file conflict with itself, which is a condition no existing rpm version checks
for.  The condition is fairly bizarre but doesn't need /usrmove to occur, it
could just as well be a packaging bug, or an admin-created symlink on a system,
of which packagers could not be aware of.

I'll have a look at the rpm side of things, but cc'ing Harald for awareness of
the issue. This could be prevented by having the /usrmove affected packages in
F < 17 explicitly conflict with filesystem >= 3 but that'd require pushing out
a big pile of updates to stable releases in order to prevent what I'd expect to
be a rather rare (and discouraged) setup (running rawhide with f16 updates
enabled).

Changing the summary to reflect the actual issue, bizarre as it seems...

(In reply to comment #5)
> since updated 'newer' package for fc16 got installed over fc18 version.

Well, this is a user error, because you should _not_ have been able to do this, if you have followed the instructions on:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17

Yes its a user error, but the warning about mixing packages from older versions could use more visibility perhaps, the issue is not limited to yum distro-upgrades. Prior to /usrmove, mixing up components from here and there hasn't been anywhere near this dangerous as long as dependencies are met and there's zero warning to the user that something could possibly go wrong in this case.

Unfortunately fixing rpm to notice the self-conflict is not the trivial one-liner it should be (due to rpm internals braindamage)

What the Fedora Project although really wants to prevent, is that F16 has a newer package than rawhide. This really sucks for updates. A lot of conflicts have been introduced by such constellations, preventing users from doing a clean update.

(In reply to comment #10)
> What the Fedora Project although really wants to prevent, is that F16 has a
> newer package than rawhide. This really sucks for updates. A lot of conflicts
> have been introduced by such constellations, preventing users from doing a
> clean update.

It's just half of the story - it's not only that package versions in updates are not correct - i.e. nothing prevents making newer package for older distro - but more problematic seems, the often many packages are getting updates only through update repo and rawhide packages are basicaly left unmaintained until package maintainer starts to care before branching is ahead - thus running without updates is quite problematic as well.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.

rpm >= 4.9.90-0.git11536.1.fc18 in rawhide now detects file conflicts on self. I'll consider backporting it to F17 where it would be needed as well, but as the required changes are not entirely trivial, lets give it a bit of rawhide soak-time first.