I don't like it. Update-alternatives system is meant for different versions of the same program or packages providing the same replaceable functionality (various versions of java, various daemons providing /usr/sbin/sendmail). This package's unify and unify from wdiff have absolutely nothing common together. Please, don't do this.

Todd R (TheBlackCat) - almost 6 years ago

I disagree. Although I agree that the situation isn't ideal, changing the upstream name means that, with no explanation, the documentation just doesn't work. The user then has to go searching around to figure out what happened to the executable they thought they were getting.

Especially considering the unify binary from wdiff is marked as experimental, rather than a core piece of functionality from the package, while the unify executable here is the primary purpose of having the package. On the other hand, renaming the wdiff version breaks compatibility with Fedora. So I think this is the less bad of the possible solutions.

Ultimately it is up to the Factory maintainers to decide. If they reject this solution I will change it. But I think it would hurt usability.

---

Jan Engelhardt (jengelh) - almost 6 years ago

reviewer

History is full of such examples — and shows that renaming is fine.

• "mt" (tape program vs. autoconf checking for a "manifest tool")
• /usr/bin/ht (ht(e) vs. tex4ht)

...

People got over renames and will continue to get over renames.

For christ sake, all the GNU tools are renamed to g* on some Unix platforms so as to not collide with the real system tools. Didn't hurt anybody in 20+ years.

---

Adam Majer (adamm) - almost 6 years ago

The correct way is rename the binaries so they don't conflict. Update alternatives is not for this.

Also, rename things in documentation and/or at least add a note in README.SUSE that the binary is renamed.

imho, @mcepl is right here. As an 'alternative' I can expect a program with a different implementation, but when throwing the same paramters at it, getting mostly compatible results. anything else is not 'an alternative'

It is definitively not the right way to work around conflicting file name.

And for arguments sake: renaming binaries is explicitly valid, as configure (autoconf) even has a standard parameter for this: %configure --program-prefix=py- just as an example.

I reverted changes in devel project - sorry for sending such change, I should have been more carefull when reviewing it.

Sorry for the trouble, then, everyone. I have renamed the other package's binary to "unify_quotes" and will supercede the other request as soon as I confirm it is building correctly.