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