PICCA Frederic-Emmanuel <frederic-emmanuel.pi...@synchrotron-soleil.fr> writes:
> I am packaging the next version of spyder which is a python IDE. Thanks for working to package useful software for Debian. > The next version will support python3 > so I need to add a spyder3 binary package which will contain > /usr/bin/spyder3 This implies (because you're naming the binary differently) that the new version will have features *incompatible* with previous versions. How so? Note that it doesn't matter what the program is implemented with; the binary should be named for what it *does* from an end-user perspective, not what it's built with. > the upstream script only create /usr/bin/spyder during the build Is that a problem? What would an end user care? Note that I'm not assuming an answer — perhaps there really is some important difference between the way the new version behaves that means a user will notice incompatibilities. But this isn't necessarily so just because of “support for Python 3”. > It is quite usuall to add a 3 at the end of the scripts for python3 > version. Maybe so, but often that is simply because of cargo-cult programming. If the programs implement effectively the same features, the programs can be named the same (and ‘update-alternatives’ would be a good choice for managing the different versions). If they do not – if the different versions implement different functionality such that the user will need to care about which one they invoke – then the programs should have different names (and ‘update-alternatives’ is *not* a good option, because this is contrary to its purpose). -- \ “Faith may be defined briefly as an illogical belief in the | `\ occurrence of the improbable.” —Henry L. Mencken | _o__) | Ben Finney -- To UNSUBSCRIBE, email to debian-python-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/85ppn2dj0w....@benfinney.id.au