(In reply to comment #2)
> Conflicts with xmlrpc-c-devel?
>
> Installing packages (4):
> xmlrpc-epi-0.51-2@x86_64 xmlrpc-epi-devel-0.51-2@x86_64
> xmlrpc-epi-debuginfo-0.51-2@x86_64 xmlrpc-epi-examples-0.51-2@x86_64
>
> 206.9kB of package files are needed. 730.5kB will be used.
>
> Confirm changes? (Y/n): y
>
> Committing transaction...
>
> error: file /usr/lib64/libxmlrpc.so from install of xmlrpc-epi-devel-0.51-2
> conflicts with file from package xmlrpc-c-devel-1.06.11-2.fc6
>
Hmm, nasty.
Well as xmlrpc-c is I would like to suggest that you rename the lib (and its
soname to libxmlrpc-epi.so.X . Can you provide a new package with this fixed?
Then I'll do a full review for you.
I just rea today that mandrake wants to include the second life client in their
next release and I want to beat them to it by having it readuy for Fedora 7 :)
So let me know if you need any help with openjpeg or the client itself.

two other thoughts --
1. should all of the subpackages have the same documentation files, or are we
going to consider that redundant? rpmlint complains about there being no
documentation in the subpackages.
2. *-examples installs the examples in %{_bindir}, and the examples have
relatively generic names. this seems like it could potentially cause conflicts
with other packages. shouldn't they be store within %doc, inside an EXAMPLES
directory or the like?

(In reply to comment #17)
> callum: have you made further progress ?
> would you like some patches to address the above issues ?
David, maybe you are interested in picking this up? Callum seems to be spending
most if its time working on secondlife itself (mostly upstream).

Hrm, I tried to post something earlier but bugzilla was b0rked at the time.
I've been in contact with some Debian people (who are working on packaging
Second Life for Debian) who have decided to take over upstream xmlrpc-epi
maintenance since the previous upstream is quite dead. They've been able to get
access to the Sourceforge project and it looks like they released a 0.52 tarball
which should have all the current needed patches merged.
They also pointed out PHP is carrying a private copy of xmlrpc-epi, they're
working on merging in the PHP changes (Which seems to consist of the same fixes
everyone else needs anyway) so PHP can be built against an external copy. Fedora
policy dictates we do likewise when this package is accepted, so I guess we need
to get the PHP maintainers in on this review...
I suggest reading through their ITP:
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=413986
I suppose if someone really wants to take this package over, I wouldn't mind. I
already have my work cut out for me with the Second Life client itself... :)
Also of note, there was a rather vague message from a Linden Lab developer
saying xmlrpc is being phased out:
https://lists.secondlife.com/pipermail/sldev/2008-March/008733.html
Which would seem to imply the use of xmlrpc-epi in the SL client may be
discontinued at some point in the hand-wavey future.

Bryan: I haven't done any further work on this. In my understanding, the reporter of a review request needs to be the eventual package maintainer. As such I would propose you begin a new review request bug, improving upon the .spec posted in this bug, and marking this review request as closed - duplicate of the new bug.

I don't understand why this is back in the queue instead of just being closed. Without a package to review and a submitter to make one, an open review ticket is completely pointless.
Bryan, if you want to submit an xmlrpc-epi package, please do so in another ticket when you're ready.