On Tuesday 30 June 2009 21:04:56 Willie Wong wrote: > On Tue, Jun 30, 2009 at 08:45:54PM +0200, Alan McKinnon wrote: > > On Tuesday 30 June 2009 19:54:10 Michael Higgins wrote: > > > Detected file collision(s): > > > > > > /usr/bin/dp > > > > > > Searching all installed packages for file collisions... > > > > > > Press Ctrl-C to Stop > > > > > > mail-client/nmh-1.1-r1 > > > /usr/bin/dp > > > > > > So, it seems both packages install the same file. WTF? Am I dead in the > > > water now? > > > > Not necessarily. Usually one would persuade one of the ebuilds to not > > build the offending file by removing some USE flag. That doesn't apply to > > those packages (no relevant USE flags) so your options are: > > > > a. figure out which of the packages you can do without, and do so. (Do > > you REALLY need a speech synthesizer?) > > b. Examine each package's output of ./configure and see if there's a way > > to disable something that will avoid collisions. Then build that package > > manually. > > c. Do b) but modify the ebuild and store it in your local overlay > > d. Put on your cowboy hat (the black one), delete /usr/bin/dp and let rip > > with > > Just as a reference: > > from nmh, you get dp, the date parser: http://linux.die.net/man/8/dp > from speech tools, you get dp, the dynamic programming tool: > http://festvox.org/docs/speech_tools-1.2.0/x2656.htm > > The second seems crucial to the operation of speech tools, the former > I am not sure. But for either it seems that they could more reasonably > belong to /usr/libexec rather than /usr/bin... > > As to Alan's suggestions: > (a) Presumeably the OP knows that he is trying to emerge speech tools. > (b) and (c) are right out, at least for speech tools, since the > functionality seems crucial. > (d) o_0 > > Let this be a lesson to would-be programmers: it doesn't hurt to make > longer, more descriptive names for programs. At the very least it > increases the pattern space to decrease chance of collision. > > My suggestion: file a bug. Hope this either gets passed to upstream, > or that someone patches the ebuild to make the packages install to > more sane locations.
With more complete information to hand now, we can see it's not so much a file collision as a name collision. I'm not so sure about picking other locations - /usr/bin/ seems to perfect place for both. But I do agree that the choice of names is stupid in the extreme. The date parser seems like a tool that will be called by other software, so changing it's name is not advised. The dynamic programming tool OTOH sounds like something only users would launch, so the name could be changed easily enough. Modify the ebuild and perform an mv in src_install until such time as upstream fixes their codebase. A hack in src_install is also much easier than hacking the Makefile during the configure step. In principle at least this sounds like a workable temporary workaround. -- alan dot mckinnon at gmail dot com
