[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#976402: Proposed official virtual packages - todo and todo.txt



David Steele writes:
> On Wed, Dec 9, 2020 at 3:21 AM Ansgar <ansgar@debian.org> wrote:
>> Given topydo just provides/conflicts with devtodo to provide the "todo"
>> binary, this seems to violate Policy 10.1 "Binaries" unless they provide
>> the same functionality.
[...]
> From where I stand, I would expect the Policy to use a different word to
> indicate something along the lines of greater API compatibility. I have no
> additional background information, though. Are you aware of any expansions
> on this text, or of any precedents that could help with a consensus process?

My understanding is that different alternatives for a binary in PATH
should provide a compatible command-line interface as one might not know
which alternative is installed.  See for example the description of
x-terminal-emulator in Policy 11.8.3 or requirements for the sendmail
program.

It is sufficient to only require some subset to be guaranteed to be
provided (as is the case for both x-terminal-emulator and sendmail: any
provider will usually also accept provider-specific options in addition
to the general ones).

David Steele writes in another mail:
> That leaves todo.txt, implemented by topydo and (hopefully, soon)
> todotxt-cli. Unfortunately, (1) has been invoked here as well - the command
> sets of the two packages are close, but not identical. Also, I'm on record
> saying an emacs script could comply if:
>   - it properly supports the "--info" argument
>   - it supports calling the hooks in the optional todo.txt-base package
>   - it provides a means to add/modify/delete/show tasks housed in a
> todo.txt-format file, noting that the format does not have to be strictly
> enforced by the package.
>
> My latest stake in the ground - I claim that the functionality of the
> todo.txt virtual package, from a Policy perspective, is defined, here, and
> that the candidates are compliant.

I think "todo.txt" is okay if providers of the "todo.txt" virtual
package provide a "/usr/bin/todo.txt" alternative that provides some
reasonable subset of the command-line interface that topydo / todo.sh /
similar tools share so that "todo.txt list", "todo.txt add laundry" and
so work.  That seems to be the case between topydo and todotxt-cli; just
opening emacs wouldn't be valid.

(As with the examples above providers can implement more than just the
common interface.)

Something like this maybe?

  - name: todo.txt
    description: command-line task management utility compatible with todo.txt CLI (http://todotxt.org)
    alternatives: [/usr/bin/todo.txt]

Ansgar


Reply to: