Bugzilla Bug 145367

Ok, I realise I'm probably one of the only people that's got clustering
software installed on the same machine as my music player daemon, but there is
good reason for it...  5:)

I'm currently testing out a patch for johntheripper that allows john to crack
passwords on a cluster, or (more aptly) on a multiprocessor system.  During the
course of trying to get this to work, I got a bit of a shock when mpirun tried
to start reading my mpd.conf.  It turns out both systems use the same config
file.

It's probably too rare a problem to be worth fixing, but I thought I'd file it
anyway just in case.  If you'd like to mark this as WONTFIX, that's fine by me.
 5:)

Actually, this is slightly worse than I first thought.  It turns out they both
write to /usr/bin/mpd, so installing one after the other will break the first
one...

FEATURES="collision-protect" for t3h win! BTW, isn't it mandatory for devs? :P

We can't really change the mpich daemon configuration file location, that's
just too nonstandard and would break stuff. It wouldn't surprise me if the same
were true for mpd. Maybe a blocker's the way to go.

Jakub: you can have collision-protect zillion times in your FEATURES, if you're
not actually using both packages - and how many people use both mpich2 and mpd
(as Mike already mentioned) ?

As for mpd.conf and /usr/bin/mpd files installed by media-sound/mpd, I really
do not want to change them from upstream's designated names. I imagine this is
the same for sys-cluster/mpich2 maintainer, so I'm afraid blocker is the only
way to go.

As a side note, Debian call their mpich2's mpd "mpich-mpd-bin".

Yep, not a problem.  Blocker sounds like the best way to go (don't forget
mpd-svn).  Thanks...  5:)

OK, added a block to both mpd an mpd-svn. Donnie added the block to mpich2, so
we're good to close this bug.

Thanks everybody.

*** Bug 179477 has been marked as a duplicate of this bug. ***