disabled selinux and rebooted tried to update the package again and got the
samething minus the selinux denials.

Try adding 


ALL: localhost

to /etc/hosts.allow fixes the problem.

was already allowed.

So did changing 'SELINUX=enforcing' to 'SELINUX=permissive' in
/etc/selinux/config and rebooting help?

no still got the same problem.  Tried with 0.1.4-7 and 0.1.4-8

i got it updated to rpcbind-0.1.4-8.fc7 by rpm -e rpcbind ... downloading the
rpm and rpm -Uvh --noscripts rpcbind-0.1.4.8...

it kept failing on the scriptlets error status 9.  not sure how to run the
scriptlets by themselves though or even look at them but anyways.  With selinux
in permissive or disabled it would just error out on the scriptlets with status 9.  

Summary
    SELinux is preventing semanage (semanage_t) "write" to pipe:[31603] (rpm_t).

...

avc: denied { write } for comm="semanage" dev=pipefs egid=0 euid=0
exe="/usr/bin/python" exit=0 fsgid=0 fsuid=0 gid=0 items=0 path="pipe:[31603]"
pid=3637 scontext=root:system_r:semanage_t:s0-s0:c0.c1023 sgid=0
subj=root:system_r:semanage_t:s0-s0:c0.c1023 suid=0 tclass=fifo_file
tcontext=root:system_r:rpm_t:s0-s0:c0.c1023 tty=tty1 uid=0

oh yea, it upgraded just fine on my x86 arch machine.  from 0.1.4-6 > -7 > -8

So can this bug be closed?

no x86 != x86_64

i found another guy that was having this problem, and he found a fix.  i am
trying to find the link to his page again.

but:

rpm -qp --scripts ./rpcbind-0.1.4-13.fc8.x86_64.rpm > rpc-script

then edit the rpc-script on the groupadd and useradd lines you need to add a
switch -o.

here is his link.  better info there.  his post is kind of wrong though because
if you do the rpm -qp --scripts <package> it outputs all the scripts the install
ones and uninstall ones.  So if you run it you end up uninstalling the user and
group stuff and executing all the files that would be in the rpm...

http://www.gudlyf.com/category/techie/

hmm to quote Gudlyf's World, 

"The ‘-o’ is necessary because, for some godforsaken reason, the reason this RPM 
 kept failing was because “32″ was not a unique userid. Thing is, it’s not in 
 /etc/passwd (note that it removes it first!), so why it’s complaining I can 
 only guess has to do with LDAP, though I haven’t had time to test yet."

What worries me about just adding a '-o' flage is what uid/gid 
would I be overriding? Plus another baffling this is why is
this an x86_64 only thing? 

To answer the first question, I wonder if the portmapper package
still exists which could be causing the confliction. 

No portmapper rpm is installed on my machine.

$: rpm -qa port*
$:

Not sure... about the USERID its overriding.  this is from my current
/etc/passwd with rpcbind updated.  Maybe the userdel/groupdel isn't being run
with rights?  Or maybe that is what is causing the selinux denial.
grep :32: /etc/passwd
rpc:!!:32:32:Rpcbind Daemon:/var/lib/rpcbind:/sbin/nologin

I have reinstalled several times, working on something else,  this always
happens, doesn't in x86 though.  I use local account sufficient option too so I
am not sure why it would be going to ldap.  I can't update ldap from the
machines I am trying to upgrade rpcbind on either.

oh wow i was on the wrong box when i posted before...  that info was from x86.

on my x86_64:
$: rpm -qa port*
$:

still no portmapper though.  There are 2 rpc users on my x86 rpcuser and rpc, on
my x86_64 box there is only 1 rpcuser.  It looks like the useradd -o didn't add
the userid and now its coming from ldap.  There are a couple files on my x86_64
box that are owned by UID 32.

I'm not understanding what you mean when you say:

"It looks like the useradd -o didn't add the userid and now its  
coming from ldap."

Could you expand please?

when it deletes the user it succeeds, but then when it tries to add the user,
rpc, back into the local password file it finds the the user rpc as uid 32 in
ldap.  The user rpc is being served out via ldap as well as it was in the local
passwd file.

So even when doing the `useradd -o rpc...` it isn't getting added back into the
local passwd file, this is causing the error when trying to update the rpm too.
 The user rpc can only get authenticated through ldap now.

I think deleting the user rpc in the rpm scripts is the wrong thing to do.  Why
not just check if it is there?  And if something in it is incorrect change it?

/code
#!/bin/sh

export IFS=$'\n'
NEWUSER=(rpc x 32 32 "Rpcbind Daemon" /var/lib/rpcbind /sbin/nologin)
EXISTINGUSER=(`sed -n '/^rpc:/s/:/\n/pg' /etc/passwd`)
DIFF=0
for i in `seq 0 ${#NEWUSER[@]}`; do
        if [[ ${NEWUSER[i]} != ${EXISTINGUSER[i]} ]]; then
                echo "${NEWUSER[i]} >< ${EXISTINGUSER[i]}"
                echo "shit, user differs in passwd file."
                DIFF=1
                exit
        fi
done
if [ $DIFF == 1 ]; then
        echo -e '\n\nsomething is jacked with the passwd file on this machine
but here is a "no brain" attempt to fix it.\nSince this obviously hasnt been
tested it will probably be in the next rpcbind rpm only for x86_64 of course
because if both packages were the same, except of course for libraries and other
dependencies that would obviously be in different places it would stand to
reason they would be easier to maintain.\nBut I digress.  Dont worry Im just
busting your balls.  I still like fedora and Im not going to go back to Windows
anytime soon.  Slackware 12.0 just came out though.\n\n'
        sed -i '/^rpc:/s/.*/rpc:x:32:32:Rpcbind
Daemon:/var/lib/rpcbind:/sbin/nolgin/' /etc/passwd
fi
/code
    
Of course this might cause inconsistencies with shadow, group and gshadow.  But
you could just not delete the account when the script starts.  Or make adding
the user into the password file since it exists in ldap not a critical error,
but i think i would rather it be in the passwd file though, I guess it would be
faster.  No i dont want rpms updating my ldap accounts.

This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'.

Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists.

Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs:
http://docs.fedoraproject.org/release-notes/

The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. 
Fedora 7 is no longer maintained, which means that it will not 
receive any further security or bug fix updates. As a result we 
are closing this bug. 

If you can reproduce this bug against a currently maintained version 
of Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.