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
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?
--
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:
> >>
> >> >
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
Dmitry Bogatov writes:
> --- 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
[2019-09-28 10:04] Sean Whitton
> 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,
[2019-09-28 08:11] Sean Whitton
> Hello,
>
> On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote:
>
> >> 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.".
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
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
[2019-09-26 17:48] Ansgar
> On Thu, 2019-09-26 at 15:26 +, Dmitry Bogatov wrote:
> > If this is the case, I'd propose wording like following:
> >
> > [ ... All packages with daemons must provide init.d scripts ...],
> > unless software is only usable, by upstream's design, when pid1 is
Hello,
On Wed 25 Sep 2019 at 03:43PM +00, Dmitry Bogatov wrote:
>> 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
Hello,
On Wed 25 Sep 2019 at 02:33PM -04, David Steele wrote:
> 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
Dmitry Bogatov writes:
> This lintian check have number of false-positives, like `foo@.service`
> files triggering complains about missing `/etc/init.d/foo@` scripts,
That's not a false positive according to current policy. See also
#911165.
> and sometimes names plainly do not match (e.g
On Thu, 2019-09-26 at 15:26 +, Dmitry Bogatov wrote:
> If this is the case, I'd propose wording like following:
>
> [ ... All packages with daemons must provide init.d scripts ...],
> unless software is only usable, by upstream's design, when pid1 is
> provided by some alternative init
[2019-09-25 18:18] Ansgar
> 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].
> +---[
[2019-09-25 11:50] David Steele
> 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
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
> > > init scripts is not something that can
David Steele writes:
> On Wed, Sep 25, 2019 at 12:18 PM Ansgar wrote:
>> 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
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
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?
>
>
[2019-09-22 16:13] David Steele
> 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.
> >
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
Hello David,
On Tue 23 Jul 2019 at 12:49PM -04, David Steele wrote:
> 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
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
Hello,
On Mon 22 Jul 2019 at 01:39pm +02, Ansgar wrote:
> On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote:
>
> What sort of dependencies are we talking about? Package-level
> dependencies (e.g. Depends: systemd-sysv directly or indirectly)?
>
>> People who don't like systemd have been
Hello,
On Mon 22 Jul 2019 at 10:15am -04, David Steele wrote:
> 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
>
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
On Mon, 22 Jul 2019 at 13:39:31 +0200, Ansgar wrote:
> What sort of dependencies are we talking about? Package-level
> dependencies (e.g. Depends: systemd-sysv directly or indirectly)?
Probably yes. systemd-cron and dbus-user-session are examples of packages
that rely on the systemd service
On Mon, 2019-07-22 at 12:01 +0100, Sean Whitton wrote:
> > "Also, SysV-style init scripts may be omitted for packages which have
> > an explicit dependency on an alternate init system."
What sort of dependencies are we talking about? Package-level
dependencies (e.g. Depends: systemd-sysv directly
Hello,
On Sun 21 Jul 2019 at 08:46PM -04, David Steele wrote:
> 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...".
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
32 matches
Mail list logo
