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
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 Wh
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 syste
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
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
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 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-i
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
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 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.
>
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
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 iden
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 m
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
> >
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 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
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 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 supp
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 criter
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
d
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
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
&g
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 tod
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
&
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.
>>
>
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 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-c
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
to
28 matches
Mail list logo
