Hi Antoine,
On Tue, Oct 29, 2024 at 09:49:42AM -0400, Antoine Beaupré wrote:
> I think I understand where you're coming from, but I fail to find a
> reference in the Debian policy about this. Section 7.4 doesn't talk
> about incompatible APIs, for example.
Indeed, it's not that explicit in policy. Interpretation varies here.
Policy very explicitly discourages the use of Conflicts in your
situation (which is not the same as forbidding it).
> I was thinking of shipping python3-ulid's in a separate binary package
> ("python3-ulid-cli"?) to allow python3-ulid and ulid-cli to be installed
> in parallel, would that fix this bug for you?
>
> Otherwise how do you suggest we proceed here?
The common way to deal with this is to rename one or both
implementations.
> How different are the two interfaces anyways?
The tech-ctte had to discuss this for the case of rename vs rename.ul
and I think this transfers well to ulid. If you cannot access the core
functionality of the tool with both providers in a compatible way,
they're too different. In this case, the command line interface is
significantly different:
task | ulid-cli | python3-ulid | notes
-------------+-----------+----------------+-------------------------
generate | ulid | ulid build |
inspect | ulid ULID | ulid show ULID | output structure differs
There is no way of using these commands in a compatible way. If there
were, update-alternatives would be a reasonable tool.
So I recommend simply renaming it to ulid-python, because the majority
of users will use the Python module rather than the CLI. Maybe also talk
to upstream whether they want to make their their implementation
compatible with ulid-cli.
Helmut
