Re: Package name conflict question
On 10/16/2016 10:07 AM, Alec Leamas wrote:
> On 16/10/16 09:35, SZ Lin (林上智) wrote:
>> I want to package python library - *uritemplate* ; however, I found
>> that there is a same name package with similar function in Debian
>> archive .
>> Do you have any suggestion on it ?
> What about following the github scheme i. e.,
> sigmavirus24-python-urltemplate? Certainly not elegant, but at least
> adhering to the "follow the upstream" principle.
You'd still need to add Conflicts: python-uritemplate to the package,
(because of the same Python package name) but that would make the new
package not coinstallable with the following rdepends:
apt-cache rdepends python-uritemplate
But that doesn't necessarily mean that this problem can't be resolved
For the sake of clarity in the discussion, let's call the package in
Debian uritemplate-1 (see ) and the package not (yet) in Debian
uritemplate-2 (see ).
If you look at <https://github.com/uri-templates/uritemplate-py/>,
it says that you can install uritemplates-1 via
pip install uritemplate
But if you look at the current PyPI metadata, you see that the current
PyPI package referes to uritemplate-2. Also consider the fact that if
you look at the git repository of uritemplate-1, the last commit is
from Dec. 2015, while uritemplate-2 has commits from this year.
To me, this looks very much like that there were initially two packages
with the same name that did very similar things. And that in August of
this year uritemplate-1 was discontinued in favor of uritemplate-2,
with some features that were initially not in uritemplate-2 merged
@林上智: When you asked uritemplate-2 upstream about the naming thing,
you only referenced the PyPI packages in the github issue, and not the
actual repository of uritempalte-1 . It would be great if you could
ask them for clarification again and see if my analysis (the previous
paragraph in this email) is correct and that uritemplate-1 is really
discontinued. Also maybe ask about API compatibility between the old
and new packages.
Because if it is correct, the proper way forward would be to not
package uritemplate-2 separately in Debian, but (assuming there's API
compatibility in the sense that current rdeps in Debian work, you'd
have to test that) to simply alter the current package in Debian to
use uritemplate-2 as it's new upstream source and update that package.
After confirming with upstream, you should contact the current
Maintainers of python-uritemplate, see .