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
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
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 pat
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.
>>
>
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 th
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
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
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
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
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 -
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
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:
> > >
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
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.
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 the
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
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
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
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.
>
> Oka
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 20
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
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
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
> > &
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-St
vailable 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 requ
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
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
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
28 matches
Mail list logo
