Le Mon, Jul 02, 2007 at 04:41:17PM +0100, Jon Dowland a écrit : > > Renaming a binary is a diversion from upstream, which we > want to minimize, in almost all cases. So, it seems that the > best approach is to contain the "damage" to the emboss > package.
Hi, In summary, here is what I will do. - For the conflict with the cons package, I agreed with the maintainer that I will rename the binary in /usr/bin and provide it under its real name under /usr/lib/emboss. - For the pscan package, the situation is almost the same, although the only feedback from the maintainer I had is that he is still maintaining his package. The policy says that unless there is an agreement we both have to rename our packages, but I will not play stupid and not require him to do so. - For the hsffig package, it is orphaned, so it has no maintainer. I am quite reluctant to rename the conflicting binary of emboss in that case. As you said, the "damage" is better confined in one package, but I think that it would be unfair that when nobody cares for a package A, the damage is to be done to package B. Not taking into account the fact that hsffig FTBFS and considered for removal, shall I prepare a NMU and submit it to a sponsor ? Lastly, about helper scripts, I was wondering about the following solution : binaries could be renamed in all packages and a script could be installed instead. If only one package is installed, it would call the binary of this package, and maybe give a warning. If both packages are installed, it would give an error. This would solve nicely the problem in the case of packages which are unlikely to be installed together. Have a nice day, -- Charles Plessy http://charles.plessy.org Wako, Saitama, Japan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
