sox: conflicts with play

[ciserlohn@…]

the sox and play port both install a binary called "play". See the attached patch for an adapted portfile.

[ryandesign@…]

Right. See ticket:28799:8 where I asked the author of the new play port if this conflict was necessary or if there was a way to avoid it. Failing a response to that inquiry, I guess we'll have to add the conflict to the sox port as in your patch.

[ciserlohn@…]

Replying to ryandesign@…:

Right. See ticket:28799:8 where I asked the author of the new play port if this conflict was necessary or if there was a way to avoid it. Failing a response to that inquiry, I guess we'll have to add the conflict to the sox port as in your patch.

Sorry about that. I got the the notification mail that you committed the play port while I was on vacation. After being home again, I had simply forgotten that issue because the ticket was already closed.

While I've didn't tested it yet, it should be possible to install the play binary under a different name. But I wouldn't recommend to do so because the play port only installs this one binary. If it is only available under a different name, no one could use the macports version of play like it is described on the play homepage, various articles on the internet or in printed java magazines. This gives the users of the macports version of play a really bad user experience.

As I understand it, it's not possible to indicate a specific port variant for the "conflicts" keyword? Maybe we could add a second non-conflicting play port and add appropriate notes to all three ports (play, play-nc and sox)? Any suggestions?

[ryandesign@…]

I'm not sure what you meant exactly, but we don't want variants or additional ports. We simply want to resolve the problem that both the "play" port and the "sox" port want to install a program called "play", by renaming one of them. Perhaps you can bring the matter to the attention of the developers of both sox and play and inquire how they would suggest we resolve this collision.

[ciserlohn@…]

Replying to ryandesign@…:

I'm not sure what you meant exactly, but we don't want variants or additional ports. We simply want to resolve the problem that both the "play" port and the "sox" port want to install a program called "play", by renaming one of them. Perhaps you can bring the matter to the attention of the developers of both sox and play and inquire how they would suggest we resolve this collision.

If I understand you correctly you suggest that one of the upstream projects change the name of the program "play"? I think this is a bad idea. Both of the project are around for several years now (in very different application domains - sound processing and web application development). Changing the name of a program would be very annoying for the existing users of the affected project/program and the value of existing documentation (outside the official one which could reflect the change) would be diminished. So I think adding "conflicts play" to sox would be the best solution.

[blackfrog1@…]

Cc Me!

[hans@…]

Replying to ciserlohn@…:

I just want to remark that SoX has been around for nearly 20 years when this java framework came along with a binary named "play".

Currently, both ports declare a conflict with each other (which is a good thing, because they are in fact in conflict), and I don't know what else to do about it. There is no way SoX is gonna rename its 'play' binary to something else.

[hans@…]

Actually, the 'play' in sox is not a binary, but a symlink to sox

• which makes no difference with respect to this problem.

Anyway, with both ports declaring a mutual conflict, I think we can close this.

[hans@…]

Can someone close this please?

[ciserlohn@…]

Replying to hans@…:

Replying to ciserlohn@…: Currently, both ports declare a conflict with each other

Actually, sox didn't. Fixed in r91165.