Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Source: debian-policy Version: 4.4.0.1 Severity: normal In section 9.11 (The Operating System/Alternate init systems), it is stated that "...any package integrating with other init systems must also be backwards-compatible with sysvinit by providing a SysV-style init script...". There is a single exception for the alternate init system implementation itself. There are other exception conditions that we may want to consider here. For instance, if a package has an explicit dependency on a particular "alternate" init system, to, say, access the systemd D-Bus interface, there is likely little value in providing sysv init scripts. I suggest that something like the following line be added to the end of the second paragraph in that section: "Also, SysV-style init scripts may be omitted for packages which have an explicit dependency on an alternate init system." -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
Bug#932704: Fwd: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
Re-sending to the bug thread. -- Forwarded message - From: David Steele Date: Mon, Jul 22, 2019 at 9:15 AM Subject: Re: Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required To: Sean Whitton On Mon, Jul 22, 2019 at 7:02 AM Sean Whitton wrote: > > We would want to be careful to word this requirement such that it did > not license maintainers to do things which block the work of those who > don't like systemd. > > -- > Sean Whitton The use of the systemd API blocks the work of those who don't like systemd. Is that something that should that be addressed by Policy? I don't think so. Under the scenario where the systemd api is used by a package, the current Policy leads down a logical path resulting in vestigial init scripts with calls to systemctl. Is that a preferred result, relative to the proposed exception? I don't see how that ultimately meets anyone's goals for alternate init support. -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Tue, Jul 23, 2019 at 11:15 AM Sean Whitton wrote: > > I think that the wording for this change should reflect the above > (unless I've misunderstood David), such that the new wording cannot be > misinterpreted to mean that the sysvinit requirement does not apply to > any package using any systemd component. That would resolve my issue, though I am not sold on the value of the additional specificity. I'll say no more than this - If I am operating in good faith, the additional language is not necessary. If I am not, it won't stop me. Dave
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton wrote: > > The Policy Editors have decided that dropping the requirement to ship > init scripts is not something that can be decided by means of the Policy > Changes Process, at least for the time being. > > In proposing and reviewing wording to resolve this bug, then, we should > be careful not to weaken the requirement to ship init scripts. > Otherwise, in resolving this bug we would be changing the requirements > to ship init scripts by means of the Policy Changes Process. > > I'm suggesting this be kept in mind. It need not result in a wordier > change, and I certainly agree with you that we should assume good faith > on the part of package maintainers. > Candidate language attached. It adds "Also excepted are packages which require a feature of an alternate init system which is not available in SysV-Style init systems.". Thoughts? -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE From 5b99099d370b6304cadaedc99d5f8d8cd3063c71 Mon Sep 17 00:00:00 2001 From: David Steele Date: Sun, 22 Sep 2019 15:53:12 -0400 Subject: [PATCH] Clarify exception to sysv init script requirement --- policy/ch-opersys.rst | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/policy/ch-opersys.rst b/policy/ch-opersys.rst index 3e685cf..41f06fa 100644 --- a/policy/ch-opersys.rst +++ b/policy/ch-opersys.rst @@ -1006,7 +1006,9 @@ supported by all init implementations. An exception to this rule is scripts or jobs provided by the init implementation itself; such jobs may be required for an implementation-specific equivalent of the ``/etc/rcS.d/`` scripts and may not have a one-to-one correspondence -with the init scripts. +with the init scripts. Also excepted are packages which require a +feature of an alternate init system which is not available in SysV-Style +init systems. .. _s-upstart: -- 2.23.0
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 11:43 AM Dmitry Bogatov wrote:
>
>
> [2019-09-22 16:13] David Steele
> > Candidate language attached. It adds "Also excepted are packages which
> > require a
> > feature of an alternate init system which is not available in SysV-Style
> > init systems.". Thoughts?
>
> Imho, it opens loophole. Sysvinit does not provide equivalent of
> sd_notify("SD_READY=1"), so any service that links to libsystemd for
> that exactly call can be argued as "requiring feature [...] which is not
> available [...]".
>
> As real life example I recall Avahi-related bug (can't find number right
> now, sorry). Two inter-dependent services, where second fails to start
> unless first is already ready to listen.
>
> I'd argue this is bug in design, but if we consider design is written in
> stone, this is a bug in init.d script that must be worked around
> somehow.
>
> With your change in place, avahi maintainers would be able to drop
> sysvinit support instead of fixing init.d script.
>
> Very strong -1.
I'm just looking to avoid the scenario where I add systemctl calls to
an init script, for a package that uses the systemd D-Bus interface.
Alternate language is solicited.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 12:18 PM Ansgar wrote: > > Hi, > > On Sun, 2019-09-22 at 16:13 -0400, David Steele wrote: > > On Tue, Jul 23, 2019 at 2:10 PM Sean Whitton > > wrote: > > > The Policy Editors have decided that dropping the requirement to ship > > > init scripts is not something that can be decided by means of the Policy > > > Changes Process, at least for the time being. > > > > > > In proposing and reviewing wording to resolve this bug, then, we should > > > be careful not to weaken the requirement to ship init scripts. > > > Otherwise, in resolving this bug we would be changing the requirements > > > to ship init scripts by means of the Policy Changes Process. > > > > > > I'm suggesting this be kept in mind. It need not result in a wordier > > > change, and I certainly agree with you that we should assume good faith > > > on the part of package maintainers. > > > > > > > Candidate language attached. It adds "Also excepted are packages which > > require a > > feature of an alternate init system which is not available in SysV-Style > > init systems.". Thoughts? > > I don't think there is a way to get such changes through the policy > process as Sean said (I tried to document what I see as current > practice in #911165). Practically the project seems to have already > decided that this is fine, even for packages that don't require > systemd: > > +--- > | There are 1033 non-overridden instances of lintian detecting a > | service unit without an init.d script [7]. > +---[ https://lists.debian.org/debian-devel-announce/2019/09/msg1.html ] > > Ansgar > Regardless of the practicality, I'd like clarity on the policy. After reading #911165, I'd say I prefer it to this proposal. But something needs to be done about the current alternate init system support language.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Wed, Sep 25, 2019 at 2:00 PM Ansgar wrote: > > Well, the Policy Editors currently see no consensus; so to change it one > would need to convince them, involve the tech-ctte or a GR. > The Policy needs to either explicitly discourage the use of systemd-specific features, or recognize the sysv-init incompatibility of packages that use them, For my part, I have no interest in participating in the init wars. I just want clear guidance on how to avoid an AUTORM-level bug report. Right now the Policy is pretty much telling me to add an init script with calls to systemctl. I'd like a different answer.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton wrote: > > Hello, > > On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > > > Reasonable. Then let's drop part about Depends: > > > > [ ... All packages with daemons must provide init.d scripts ...], > > unless software is only usable, by upstream's design, when > > pid1 is provided by some other init system. > > I think this would work. What do you think, David? I don't know. It provides more clarity the original Policy question, but raises a technical one I don't know the answer to. For my special case, is it practical to use systemd (via D-Bus) to manage system daemon start/stop when it is not pid1? If yes, things may have gotten worse (I'm responsible for getting this all to work correctly?). In that case I would prefer a statement discouraging systemd-specific features.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sat, Oct 5, 2019 at 1:06 PM Sean Whitton wrote: > > Hello David, > > On Sun 29 Sep 2019 at 10:35AM -04, David Steele wrote: > > > On Sat, Sep 28, 2019 at 1:05 PM Sean Whitton > > wrote: > >> > >> Hello, > >> > >> On Sat 28 Sep 2019 at 04:18PM +00, Dmitry Bogatov wrote: > >> > >> > Reasonable. Then let's drop part about Depends: > >> > > >> > [ ... All packages with daemons must provide init.d scripts ...], > >> > unless software is only usable, by upstream's design, when > >> > pid1 is provided by some other init system. > >> > >> I think this would work. What do you think, David? > > > > I don't know. It provides more clarity the original Policy question, but > > raises > > a technical one I don't know the answer to. For my special case, is it > > practical to use systemd (via D-Bus) to manage system daemon > > start/stop when it is > > not pid1? If yes, things may have gotten worse (I'm responsible for getting > > this > > all to work correctly?). > > Unfortunately, there isn't quite enough context in your reply for me to > understand exactly how you think this makes things worse for you. Could > you expand, please? I'm going to drop my objection, and assume that this is saying I don't need to write init scripts for my special case.
Bug#932704: debian-policy: Don't force sysvinit compatibility if e.g. alternate init required
On Sun, Oct 6, 2019, 8:17 PM Sean Whitton wrote: > Hello, > > On Sat 05 Oct 2019 at 07:30PM -04, David Steele wrote: > > > I'm going to drop my objection, and assume that this is saying I don't > need to > > write init scripts for my special case. > > Okay -- perhaps you'd like to second Dmitry's patch, then, if you think > it reflects project consensus? > I'm abstaining. >
Bug#976402: Proposed official virtual packages - todo and todo.txt
Package: debian-policy Severity: wishlist X-Debbugs-Cc: debian-de...@lists.debian.org, charlesmel...@outlook.com, on...@debian.org thanks I'd like to propose adding the virtual packages "todo" and "todo.txt" to the authoritative list of virtual package names. I'm submitting this per Policy section 3.6 and the preamble to the [authoritative list]. [Todo.txt] describes an ecosystem of task management tools that revolve around a standard for a freeform-text tasking file. The reference cli has been packaged for some time, as "todotxt-cli". It provides the executable "todo-txt". An alternative cli provider, "topydo", has been recently added, adding an executable by the same name. I propose uniting this packages using the name "todo" - the common name for the utility. Since not all todo list packages that may want to share that name conform to the todo.txt standards, I also propose "todo.txt", a strict subset of "todo", for packages which conform. Note that topydo already implements these virtual packages, and that there now exists a todo.txt-base packages that extends cli todo.txt capabilities. There is also a todo.txt-cli package in Sid. This is redundant, and has a pending RM request. I did a screen scrape of p.d.o to find any possible collisions for these names. There is a single package, devtodo (popcon 74, recently ITA'd), that installs a "todo" executable. Currently, topydo Conflicts with this package. I'd propose adding it to the "todo" virtual package. This is a request for comment per the procedure in the list. Please copy replies to this bug report. [authoritative list]: https://www.debian.org/doc/packaging-manuals/virtual-package-names-list.yaml [Todo.txt]: http://todotxt.org/ signature.asc Description: OpenPGP digital signature
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 12:30 PM Bill Allombert wrote: > > Does all theses tools provide an compatible interface ? > In other word, are there interoperable ? > Yes, topydo and todotxt-cli support common commands, which make them interoperable for most uses. However, the command sets are not identical.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert wrote: > What about devtodo ? > > Reading your summary, it seems that the todo.txt virtual package > is well specified, but the todo one is not. > > Do you envision to have packages depending on todo and then use the > todo binary ? > No. This is a means to allow topydo and todotxt-cli to use "todo" without crowding devtodo. I believe this meets the definition of a virtual package in the Policy. I do see the desirability for packages to be able to Depend on todo.txt, with an expectation of the command line format beneath (e.g. support for a todo.txt schema).
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 4:42 PM Bill Allombert wrote: > On Fri, Dec 04, 2020 at 01:34:44PM -0500, David Steele wrote: > > On Fri, Dec 4, 2020 at 1:15 PM Bill Allombert > wrote: > > > > > Do you envision to have packages depending on todo and then use the > > > todo binary ? > > > > > > > No. This is a means to allow topydo and todotxt-cli to use "todo" without > > crowding devtodo. I believe this meets the definition of a virtual > package > > in the Policy. > > I am not use I understand. Do you plan for /usr/bin/todo to be managed by > update-alternatives ? That would require all alternatives to share a common > interface. > The guidance in the Policy is that alternatives "offer more-or-less the same functionality". I believe this standard is met.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert wrote: > > Are people using /usr/bin/todo in script or Makefile ? > Are they likely to still work with the alternatives ? > I'd say no. It is an interactive end-user command. This gives flexibility in what they are interacting with.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 6:21 PM David Steele wrote: > > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert wrote: > >> >> Are people using /usr/bin/todo in script or Makefile ? >> Are they likely to still work with the alternatives ? >> > > I'd say no. It is an interactive end-user command. > > This gives flexibility in what they are interacting with. > This is no more of a stretch than "vi" implementing "editor". -- AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Fri, Dec 4, 2020 at 6:39 PM Bill Allombert wrote: > On Fri, Dec 04, 2020 at 06:23:44PM -0500, David Steele wrote: > > On Fri, Dec 4, 2020 at 6:21 PM David Steele wrote: > > > > > > > > On Fri, Dec 4, 2020 at 5:54 PM Bill Allombert > wrote: > > > > > >> > > >> Are people using /usr/bin/todo in script or Makefile ? > > >> Are they likely to still work with the alternatives ? > > >> > > > > > > I'd say no. It is an interactive end-user command. > > > > > > This gives flexibility in what they are interacting with. > > > > > > > This is no more of a stretch than "vi" implementing "editor". > > Note that even in this case there is a minimal common interface required > so that programms can call '/usr/bin/editor file' to let the user edit > 'file'. > With devtodo added to the providers, the core "todo" capability will always give you a list of current tasks. Devtodo uses different endpoints to go beyond that capability. https://www.mankier.com/1/devtodo
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 9, 2020 at 3:21 AM Ansgar 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.
>
Note that there is a Conflicts because the current devtodo
does not support alternatives.
As I've said elsewhere, I claim they do provide the same functionality, and
are
not in violation of 10.1. I say "topydo and devtodo provide the same
functionality - the ability to add, delete, modify, and display discrete
tasking information". That is not a false statement. The question is, does
it reflect the intent of the Policy?
>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?
> Different "todo" managers should be coinstallable as different users
> might want to use different ones.
>
The scheme I propose allows that.
> From the messages I thought todo.txt is a standard *text* format, but
> now you say it is a standard command-line interface? What can they do
> if they depend on todo.txt?
>
Todo.txt is an ecosystem of tools built around a file format. There is a
canonical
CLI implementation. Topydo was built as an alternative to that. I'm sorry,
but I'm
not sure I understand your question beyond that.
For the most part, todo.txt is an end user tool. As for a theoretical
package
that depends on todo.txt, I believe that the core capabilities it requires
of
todo.txt are:
- a mechanism for discovering the location of the active tasking file
- an optional mechanism for adding pre and post processing hooks to
task modification activities
These capabilities are present in topydo, with the help of todo.txt-base.
> This seems to imply I can manage tasks from the command-line like "todo
> new-task eat breakfast"? What interface to do so is provided? Can I
> call "todo ", "todo", "todo new-task ", ...?
>
It depends. Topydo can run one-off commands (arg[1] is the command, with a
default of "ls" - the same as devtodo). It also has an interpreter mode and
a
GUI mode, which I do not believe are pertinent to the discussion.. Devtodo
has one-off commands as well, along with other end point to support specific
commands.
> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)?
>
Again, not sure I understand. To be sure, emacs could be used to edit the
file,
if it knows where it is. Note that part of the virtual packages work-up
involves
automatic discovery of the file location across providers (see
todo.txt-base -
https://manpages.debian.org/unstable/todo.txt-base/index.html).
I'm adding a common "--info" argument to all todo.txt providers. An emacs
todo script could use that to identify a todo file to open. But, the core
"todo{.txt}" command does not open the file for editing. See the vitodo
and edittodo commands in todo.txt-base for something similar to what
you are talking about.
All of this is in preparation for another layer of capabilities for todo.txt
providers which is not submitted yet.
If your theoretical emacs script met the criterion I listed above ("--info"
and hooks), I'd say it is worth discussing if that could be a
todo.txt provider.
It appears that a virtual package, or at least these virtual packages in
particular,
need a distinct spec separate from their implementations. Where would
you expect to find that documentation? Should that spec be part of this
list application process?
> If it is just to have "todo" open a user-chosen program they like to
> manage their todo lists with, why not just have the user add a "todo"
> alias to their shell or $HOME/bin?
>
This standardizes that process. Part of the challenge with these tool sets
is the variety of things you have to do to get them to a common working
level. My goal in packaging them is to simplify that as much as
possible
> > - name: todo.txt
> > description: task management based on a standard free-form text
> format
>
> This description seem to vague to me: it doesn't even mention what file
> format. Does a package providing todo.txt provide any specific user
> interface? Emacs can edit todo.txt files: would it qualify (even
> without a "todo" executable in $PATH)?
>
> Ansgar
>
Ok ... does anyone have guidance on the line length limit in that yaml file?
Could you take a stab at a replacement?
BTW - https://salsa.debian.org/debian/todotxt-cli/-/merge_requests/2
I'll just say here that your stance feels unnecessarily aggressive from the
viewpoint of my inbox. I'm just trying to add value here.
--
AE0D BF5A 92A5 ADE4 9481 BA6F 8A31 71EF 3661 50CE
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 9, 2020 at 2:44 PM David Steele wrote: > > > On Wed, Dec 9, 2020 at 3:21 AM Ansgar wrote: > >> >> >> Should emacs provide a "todo" script to open ~/TODO (with say org-mode)? >> > In regards to org mode. I'd add a third criteria - the expectation that the underlying file complies with the todo.txt format, though there is no requirement that the provider enforce that.
Bug#976402: Proposed official virtual packages - todo and todo.txt
control: tag -1 + patch
On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton
wrote:
>
> Could you provide an actual patch against policy.git, please, for
> seconding? See README.md in policy.git for more info.
>
> --
> Sean Whitton
>
https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
diff --git a/virtual-package-names-list.yaml
b/virtual-package-names-list.yaml
index 2a9857a..11afe1e 100644
--- a/virtual-package-names-list.yaml
+++ b/virtual-package-names-list.yaml
@@ -65,6 +65,9 @@ virtualPackages:
- name: tclsh
description: a /usr/bin/tclsh
alternatives: [/usr/bin/tclsh]
{+- name: todo.txt+}
{+ description: a command-line task management utility compatible with
todo.txt CLI (http://todotxt.org)+}
{+ alternatives: [/usr/bin/todo.txt]+}
- name: wish
description: a /usr/bin/wish
alternatives: [/usr/bin/wish]
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton wrote: > > > Putting aside the use of the alternatives system, why is a virtual > package wanted? When would it be useful to be able to declare a > dependency and have it satisfied by one of these implementations? > > As an example, a future rev of an integrated todo.txt-gtd[1] would depend on that virtual package. [1]: https://github.com/davesteele/todo.txt-gtd
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Mon, Dec 14, 2020 at 5:29 PM David Steele wrote: > > On Mon, Dec 14, 2020 at 3:48 PM Sean Whitton > wrote: > >> >> >> Putting aside the use of the alternatives system, why is a virtual >> package wanted? When would it be useful to be able to declare a >> dependency and have it satisfied by one of these implementations? >> >> > As an example, a future rev of an integrated todo.txt-gtd[1] would depend > on that virtual package. > > [1]: https://github.com/davesteele/todo.txt-gtd > > Somehow I don't have a copy or your reply. Imagine that tdtcleanup is a pre/post hook in todo.txt-base. An implementation of todo.txt is needed to make use of it.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton wrote: > > Okay, and you expect every implementation of todo.txt to have > tdtcleanup? I think we probably want to specify that as one of the (or > the only?) requirements of the virtual package. > No, no. The gtd stuff is an optional add-on to todo.txt. The requirements on todo.txt to support these types of add-ons I listed earlier in the thread.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Wed, Dec 16, 2020 at 2:34 PM David Steele wrote: > > > On Wed, Dec 16, 2020 at 2:14 PM Sean Whitton > wrote: > >> >> Okay, and you expect every implementation of todo.txt to have >> tdtcleanup? I think we probably want to specify that as one of the (or >> the only?) requirements of the virtual package. >> > > No, no. > > The gtd stuff is an optional add-on to todo.txt. The requirements on > todo.txt to support these types of add-ons I listed earlier in the thread. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=976402#98
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Mon, Dec 14, 2020 at 5:29 PM David Steele wrote:
> On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton
> wrote:
>
>>
>> Could you provide an actual patch against policy.git, please, for
>> seconding? See README.md in policy.git for more info.
>>
>> --
>> Sean Whitton
>>
>
>
> https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
>
> diff --git a/virtual-package-names-list.yaml
> b/virtual-package-names-list.yaml
> index 2a9857a..11afe1e 100644
> --- a/virtual-package-names-list.yaml
> +++ b/virtual-package-names-list.yaml
> @@ -65,6 +65,9 @@ virtualPackages:
> - name: tclsh
>description: a /usr/bin/tclsh
>alternatives: [/usr/bin/tclsh]
> {+- name: todo.txt+}
> {+ description: a command-line task management utility compatible with
> todo.txt CLI (http://todotxt.org)+}
> {+ alternatives: [/usr/bin/todo.txt]+}
> - name: wish
>description: a /usr/bin/wish
>alternatives: [/usr/bin/wish]
>
Second seconds request.
Bug#976402: Proposed official virtual packages - todo and todo.txt
control: tag -1 - moreinfo
On Mon, Dec 21, 2020 at 11:32 AM David Steele wrote:
>
>
> On Mon, Dec 14, 2020 at 5:29 PM David Steele wrote:
>
>> On Mon, Dec 14, 2020 at 3:42 PM Sean Whitton
>> wrote:
>>
>>>
>>> Could you provide an actual patch against policy.git, please, for
>>> seconding? See README.md in policy.git for more info.
>>>
>>> --
>>> Sean Whitton
>>>
>>
>>
>> https://salsa.debian.org/steele/policy/-/tree/bug976402-steele
>>
>> diff --git a/virtual-package-names-list.yaml
>> b/virtual-package-names-list.yaml
>> index 2a9857a..11afe1e 100644
>> --- a/virtual-package-names-list.yaml
>> +++ b/virtual-package-names-list.yaml
>> @@ -65,6 +65,9 @@ virtualPackages:
>> - name: tclsh
>>description: a /usr/bin/tclsh
>>alternatives: [/usr/bin/tclsh]
>> {+- name: todo.txt+}
>> {+ description: a command-line task management utility compatible with
>> todo.txt CLI (http://todotxt.org)+}
>> {+ alternatives: [/usr/bin/todo.txt]+}
>> - name: wish
>>description: a /usr/bin/wish
>>alternatives: [/usr/bin/wish]
>>
>
> Second seconds request.
>
>
I'm not aware of any other inputs expected of me.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On Sun, Jan 10, 2021 at 11:53 AM Novy, Ondrej wrote: > On Sat, 2 Jan 2021 14:20:57 +0100 Bill Allombert > wrote: > > What Sean meant is that, at this stage, this proposal needs to be > > seconded by people impacted by this virtual package before being > > accepted. > > as maintainer of todotxt-cli I second this. > > -- > Best regards > Ondřej Nový > > I'm not aware of anyone else directly affected by this.
Bug#976402: Proposed official virtual packages - todo and todo.txt
On 1/27/22 5:11 PM, Sean Whitton wrote: Hello David, ... Reviewing this bug, it is still not clear to me that a virtual package is wanted as opposed to just making /usr/bin/todo a path managed by the alternatives system. I'm closing the bug, but if development that has taken place in the todo.txt world since our previous dicsussion has changed matters such that there are concrete usecases for the virtual packages that you can explain, then please consider opening a new bug with that explanation. We have a significant disconnect here. The todo.txt-base (and gtd) packages place more requirements on an alternative implementations other than just owning the name. The proposed virtual package would codify that contract. That represents a concrete set of use cases, laid out previously in this thread, in Dec 2020 (the stuff about autodiscovery of the datafile, and support of hooks - both allow todo.txt-gtd to properly interact). The packages that interact with todo.txt are released: https://tracker.debian.org/pkg/todo.txt-base https://github.com/davesteele/todo.txt-base https://packages.debian.org/sid/todo.txt-gtd Also, aesthetically, I believe that Debian should have a package named todo.txt that installs todo.txt-cli by default. OTOH, I undertook this process only because Ondrej required it before supporting integration of todo.txt-cli with todo.txt-base. I'd be happy to support the majority consensus between the three of us on how to proceed. OpenPGP_signature Description: OpenPGP digital signature
