Bug#727708: init system coupling etc.

[Ian Jackson]

I see that the resolutions I proposed on Sunday have been voted down
(or are likely to be voted down).  Without the wider scope of the GR
separately rider (which looks unlikely to pass), my T-vs-L individual
resolution is actively harmful because it's not GR-overrideable in
itself so:

FORMAL ACTION: I hereby change my vote on "Init system coupling call
for votes" to FD.

I still want to vote on L.  If we're not having a separate wide scope
GR override, we need to add the GR rider to all relevant resolutions.

FORMAL ACTION: I therefore hereby formally propose the following
resolution ("init system coupling v2"), but do not yet call for votes.

[rationale]

   The default init system decision is limited to selecting a default
   initsystem for jessie.  We expect that Debian will continue to
   support multiple init systems for the foreseeable future; we
   continue to welcome contributions of support for all init systems.

[rubric]

   Therefore, for jessie and later releases, we exercise our power to
   set technical policy (Constitution 6.1.1):

[loose coupling]

   Software outside of an init system's implementation may not require
   a specific init system to be pid 1, although degraded operation is
   tolerable.

   Maintainers are encouraged to accept technically sound patches
   to enable improved interoperation with various init systems.

[GR rider]

   If the project passes (before the release of jessie) by a General
   Resolution, a "position statement about issues of the day", on the
   subject of init systems, the views expressed in that position
   statement entirely replace the substance of this TC resolution; the
   TC hereby adopts any such position statement as its own decision.

   Such a position statement could, for example, use these words:

  The Project requests (as a position statement under s4.1.5 of the
  Constitution) that the TC reconsider, and requests that the TC
  would instead decide as follows:

I intend to call for votes on this (with whatever amendments anyone
chooses to propose) at 14:30 UTC on Friday (around 48h from now).  IMO
there has been plenty of time to try to develop a better wording.

If no-one from the T side has proposed an amendment along the lines of
T, then I will put the exact wording of the T as currently found in
git on the ballot too.

As might be expected, I am contemplating proposing and/or sponsoring a
GR.  Now that the default resolution has passed, a simple majority GR
has the power to decide init system questions using the TC's powers.

At the moment I think I will definitely do this if:

 * The vote on the proposal above results in FD.  (I think it is
   important to make a decision on this quickly before "facts on the
   ground" are established to make this more difficult; the passage of
   the default resolution makes that urgent.)

 * Anyone in the TC Calls for Votes on a proposal I consider related
   to the coupling question without giving me an opportunity to
   propose an alternative text as an amendment.  In this case I would
   propose a GR immediately.

 * Anyone in the TC Calls for Votes on any proposal related to init
   systems, without giving me an opportunity to propose an alternative
   text as an amendment, in a manner I consider prejudicial.

If the TC's conclusion on the coupling question is IMO not
sufficiently robust I will probably canvass opinions before deciding
whether to propose a GR.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21243.32848.338268.802...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Lucas Nussbaum]

Hi,

I must admit that I only followed this part of the discussion from a
distance.

However, one thing really strikes me:

On 12/02/14 at 14:08 +, Ian Jackson wrote:
> [loose coupling]
> 
>Software outside of an init system's implementation may not require
>a specific init system to be pid 1, although degraded operation is
>tolerable.

This is super vague. What does being "outside of an init system's
implementation" mean? What does "degraded operation" mean?

If you really want to have that discussion now, rather than wait for
actual, concrete problems to discuss, I'd suggest that you build a few
hypothetical scenarios, and discuss them. And then build a resolution
that represents the aggregated opinions on those few hypothetical
scenarios.

But I also don't really understand why there's a particular urgency
for the TC to rule on that. Are there packages with tight coupling
already in the archive?

Lucas


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140212170938.gb16...@xanadu.blop.info

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson  writes:

> [loose coupling]
>
>Software outside of an init system's implementation may not require
>a specific init system to be pid 1, although degraded operation is
>tolerable.
>
>Maintainers are encouraged to accept technically sound patches
>to enable improved interoperation with various init systems.

I agree with you that this is an important issue which needs to be
resolved within the Debian project. I also want to make it clear that I
support the goal of having the project provide a clear policy statement
about this issue in the short term.

The discussions held within the context of the default init bug were
fruitful, and without rancor, which makes me hopeful that the project
membership can drive this issue to consensus in the near future through
the usual policy editing process. As such I'd like to amend this
proposed ballot with an additional option:

 * The TC chooses to not pass a resolution on this issue at the current time.

This is different from FD as it says the TC will not continue
discussions on this issue, although it could well restart them if the
people involved in the policy editing process come to an impasse. It's
also different from 'T' in that it will allow us to revisit this in the
future without needing to overturn a previous decision.

I understand your desire to forestall potential future conflict by
proactively voting this issue, but given the progress already made, I
don't feel like the TC needs to step in now.

Thank you for your consideration.

-- 
keith.pack...@intel.com


pgp3RohzTkwhJ.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Russ Allbery]

Ian Jackson  writes:

> FORMAL ACTION: I therefore hereby formally propose the following
> resolution ("init system coupling v2"), but do not yet call for votes.

> [rationale]

>The default init system decision is limited to selecting a default
>initsystem for jessie.  We expect that Debian will continue to
>support multiple init systems for the foreseeable future; we
>continue to welcome contributions of support for all init systems.

> [rubric]

>Therefore, for jessie and later releases, we exercise our power to
>set technical policy (Constitution 6.1.1):

> [loose coupling]

>Software outside of an init system's implementation may not require
>a specific init system to be pid 1, although degraded operation is
>tolerable.

>Maintainers are encouraged to accept technically sound patches
>to enable improved interoperation with various init systems.

> [GR rider]

>If the project passes (before the release of jessie) by a General
>Resolution, a "position statement about issues of the day", on the
>subject of init systems, the views expressed in that position
>statement entirely replace the substance of this TC resolution; the
>TC hereby adopts any such position statement as its own decision.

>Such a position statement could, for example, use these words:

>   The Project requests (as a position statement under s4.1.5 of the
>   Constitution) that the TC reconsider, and requests that the TC
>   would instead decide as follows:

I propose the following text as an amendment to this option.  It would
replace this text in its entirety, including the [GR rider] section.  (I
don't see any need for or purpose served by cancelling technical advice to
the project based on a GR outcome.  All the members of the project are, I
think, capable of using their own judgement to resolve technical advice
with the substance of a GR, and technical advice is by definition not
binding.  Plus, I think this is a basically sensible thing to say
regardless of the chosen init system.)

Please note that I personally am currently leaning towards voting Keith's
proposal above the one that I'm proposing in this message for the reasons
that he states in that message.  But I think it's useful to have a
statement on the ballot so that it can be ranked, since it may be a
compromise position between deferring to the Policy process and Ian's
proposal.

The following is technical advice offered to the project by the
Technical Committee under section 6.1.5 of the constitution.  It does
not constitute an override of maintainer decisions past or future:

Packages should normally support the default Linux init system.  There
are some exceptional cases where lack of support for the default init
system may be appropriate, such as alternative init system
implementations, special-use packages such as managers for non-default
init systems, and cooperating groups of packages intended for use with
non-default init systems.  However, package maintainers should be
aware that a requirement for a non-default init system will mean the
package will be unusable for most Debian users and should normally be
avoided.

Package maintainers are strongly encouraged to merge any contributions
for support of init systems other than the Linux default, and to add
that support themselves if they're willing and capable of doing so.
In particular, package maintainers should put a high priority on
merging changes to support any init system which is the default on one
of Debian's non-Linux ports.

For the jessie release, all packages that currently support being run
under sysvinit should continue to support sysvinit unless there is no
technically feasible way to do so.  Reasonable changes to preserve or
improve sysvinit support should be accepted through the jessie
release.  There may be some loss of functionality under sysvinit if
that loss is considered acceptable by the package maintainer and the
package is still basically functional.  All packages should support
smooth upgrades from wheezy to jessie, including upgrades done on a
system booted with sysvinit.

The Technical Committee offers no advice at this time on requirements
or package dependencies on specific init systems after the jessie
release.  There are too many variables at this point to know what the
correct course of action will be.

I'm also happy to consider amendments to this text along the lines of
Steve's proposed language elsewhere in the thread.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3d01ag5@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Keith Packard]

Russ Allbery  writes:

> The following is technical advice offered to the project by the
> Technical Committee under section 6.1.5 of the constitution.  It does
> not constitute an override of maintainer decisions past or future:

Thanks for making this clear -- operating under §6.1.5 means that this
doesn't conflict with §6.3.6 as it is not a decision.

I remain unsure about how §6.3.5 should inform this process; there's a
fuzzy line between 'advice' and 'design', and I just don't know where
this particular text falls.

I do like the sentiments expressed in the text though, and I hope we'll
see broad consensus form around something akin to it.

-- 
keith.pack...@intel.com


pgpgga2PX63RO.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Adrian Bunk]

On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
>...
> All packages should support
> smooth upgrades from wheezy to jessie, including upgrades done on a
> system booted with sysvinit.
>...

This sounds like a statement by the TC that smooth upgrades from wheezy 
to jessie will only be optional and that it is OK[1] for a package to
not support that.

Debian has a pretty good reputation for smooth upgrades, so any
statement that weakens this default is a pretty strong message.

cu
Adrian

[1] at least not RC-buggy, which would otherwise be the default

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140212192948.ga27...@bunk.dyndns.info

Bug#727708: init system coupling etc.

[Russ Allbery]

Adrian Bunk  writes:
> On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:

>>...
>> All packages should support
>> smooth upgrades from wheezy to jessie, including upgrades done on a
>> system booted with sysvinit.
>>...

> This sounds like a statement by the TC that smooth upgrades from wheezy
> to jessie will only be optional and that it is OK[1] for a package to
> not support that.

Three observations to that:

* This is technical advice.  I think it is inappropriate to use wording
  stronger than "should" in technical advice.

* This is explicitly not a maintainer override of anyone, which obviously
  includes the release team (even assuming that the TC could override the
  release team, which I don't believe it can given that the release team's
  authority flows from the DPL via delegation).  The release team sets the
  policy for RC bugs, not the TC.

* This is technical advice, not technical policy, and therefore obviously
  does not override what Policy already says.

If there is an alternative wording that fits those constraints that people
would prefer, I'm certainly happy to consider it for incorporation into my
proposed amendment.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqh0yvio@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Sam Hartman]

When I've found myself trying to avoid normative language  in situations
like this I end up with statements like:

It is important that all packages support smoothe upgrades from Wheezy
to Jessie , even when the system is booted with sysvinit.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/tsl8utgrufb@mit.edu

Bug#727708: init system coupling etc.

[Matthias Urlichs]

Hi,

> >>...
> >> All packages should support
> >> smooth upgrades from wheezy to jessie, including upgrades done on a
> >> system booted with sysvinit.
> >>...
> 
> If there is an alternative wording that fits those constraints that people
> would prefer, I'm certainly happy to consider it for incorporation into my
> proposed amendment.
> 
How about 

Policy (cite §§?) mandates that all packages support smooth upgrades from
wheezy to jessie. This should apply regardless of which init system is
running at the time of upgrade.

> 
-- 
-- Matthias Urlichs


signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Adrian Bunk]

On Wed, Feb 12, 2014 at 11:35:11AM -0800, Russ Allbery wrote:
> Adrian Bunk  writes:
> > On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
> 
> >>...
> >> All packages should support
> >> smooth upgrades from wheezy to jessie, including upgrades done on a
> >> system booted with sysvinit.
> >>...
> 
> > This sounds like a statement by the TC that smooth upgrades from wheezy
> > to jessie will only be optional and that it is OK[1] for a package to
> > not support that.
> 
> Three observations to that:
> 
> * This is technical advice.  I think it is inappropriate to use wording
>   stronger than "should" in technical advice.
> 
> * This is explicitly not a maintainer override of anyone, which obviously
>   includes the release team (even assuming that the TC could override the
>   release team, which I don't believe it can given that the release team's
>   authority flows from the DPL via delegation).  The release team sets the
>   policy for RC bugs, not the TC.
> 
> * This is technical advice, not technical policy, and therefore obviously
>   does not override what Policy already says.
> 
> If there is an alternative wording that fits those constraints that people
> would prefer, I'm certainly happy to consider it for incorporation into my
> proposed amendment.

  The general rule that all packages have to support upgrades from 
  the previous stable release should not be changed. Neither should
  it be amended to make exceptions depending on which init system was
  booted at the time of the upgrade.


cu
Adrian


-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140212205246.gb27...@bunk.dyndns.info

Bug#727708: init system coupling etc.

[Adrian Bunk]

On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
> Hi,
> 
> I must admit that I only followed this part of the discussion from a
> distance.
> 
> However, one thing really strikes me:
> 
> On 12/02/14 at 14:08 +, Ian Jackson wrote:
> > [loose coupling]
> > 
> >Software outside of an init system's implementation may not require
> >a specific init system to be pid 1, although degraded operation is
> >tolerable.
> 
> This is super vague. What does being "outside of an init system's
> implementation" mean? What does "degraded operation" mean?
> 
> If you really want to have that discussion now, rather than wait for
> actual, concrete problems to discuss, I'd suggest that you build a few
> hypothetical scenarios, and discuss them. And then build a resolution
> that represents the aggregated opinions on those few hypothetical
> scenarios.
> 
> But I also don't really understand why there's a particular urgency
> for the TC to rule on that. Are there packages with tight coupling
> already in the archive?

One of the Debian GNOME maintainers has stated in this discussion[1]:

  But there are no realistic solutions for having GNOME support multiple 
  init systems in jessie.

Whether that's actually true is another question, but a maintainer 
speaking like this clearly shows that it is not only a theoretical
question.


Another reason for urgency is that there was actually consensus
in the TC that Debian should multiple init systems.[2] That was
completely lost in all the "Debian chooses systemd" headlines that
followed a widely published resolution that was only about the default 
and didn't cover that aspect.

Or perhaps that's no longer urgent, since the "Debian chooses systemd"
headlines are already in everyone's head, and a later statement
"but we also support other init systems" would anyway not make it
into the news.


> Lucas

cu
Adrian

[1] https://lists.debian.org/debian-ctte/2014/01/msg00550.html
[2] the dispute in the TC was about whether depedencies on a specific 
init system should be allowed - that in general multiple init 
systems should be supported was consensus among TC members

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140212213042.gc27...@bunk.dyndns.info

Bug#727708: init system coupling etc.

[Ian Jackson]

Lucas Nussbaum writes ("Bug#727708: init system coupling etc."):
> I must admit that I only followed this part of the discussion from a
> distance.

Fair enough.

> On 12/02/14 at 14:08 +, Ian Jackson wrote:
> > [loose coupling]
> > 
> >Software outside of an init system's implementation may not require
> >a specific init system to be pid 1, although degraded operation is
> >tolerable.
> 
> This is super vague. What does being "outside of an init system's
> implementation" mean? What does "degraded operation" mean?

Yes.  I agree that it's vague.  I'm open to better and clearer
suggestions.  When I wrote this I was hoping that the policy process
would be able to refine the details but perhaps that's overoptimistic.

I'm also open to suggestions that we should extend the discussion
period to facilitate improvements to this and other options.  How long
do people think we need ?

(I'll deal with the rest of your mail later.)

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21243.63264.602888.46...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Sjoerd Simons]

On Wed, 2014-02-12 at 23:30 +0200, Adrian Bunk wrote:
> On Wed, Feb 12, 2014 at 06:09:38PM +0100, Lucas Nussbaum wrote:
> > Hi,
> > 
> > I must admit that I only followed this part of the discussion from a
> > distance.
> > 
> > However, one thing really strikes me:
> > 
> > On 12/02/14 at 14:08 +, Ian Jackson wrote:
> > > [loose coupling]
> > > 
> > >Software outside of an init system's implementation may not require
> > >a specific init system to be pid 1, although degraded operation is
> > >tolerable.
> > 
> > This is super vague. What does being "outside of an init system's
> > implementation" mean? What does "degraded operation" mean?
> > 
> > If you really want to have that discussion now, rather than wait for
> > actual, concrete problems to discuss, I'd suggest that you build a few
> > hypothetical scenarios, and discuss them. And then build a resolution
> > that represents the aggregated opinions on those few hypothetical
> > scenarios.
> > 
> > But I also don't really understand why there's a particular urgency
> > for the TC to rule on that. Are there packages with tight coupling
> > already in the archive?
> 
> One of the Debian GNOME maintainers has stated in this discussion[1]:
> 
>   But there are no realistic solutions for having GNOME support multiple 
>   init systems in jessie.
> 
> Whether that's actually true is another question, but a maintainer 
> speaking like this clearly shows that it is not only a theoretical
> question.

Please don't quote people out of context. The problem with quoting lines
like that is that "support" means different things to different people.

The definition of "support" has two extremes:
  * Fully functional, all features work as they should etc.
  * Degraded but functional, It's usable but some functionality might
not work, errors may show up in some places etc.

Re-reading Joss' mail i can only assume with support he means the former
option. However lets not make this about rehashing the mail of one of my
fellow GNOME maintainers.

So for some less hypothetical, more practical considerations:

As long as there is a logind implementations available in Debian which
works with non-systemd, Gnome can depend on that as an alternative to
the systemd provided version and it should be possible to at least
support degraded mode for other init system for the foreseeable future.

As things stand, there seems to be more then enough motivation to ensure
an implementation of the logind interfaces is available for use on
non-systemd even when the systemd package get moved to a newer version
and it's own implementation does not support that anymore. In which case
we can add an alternate dependency on an alternate logind implementation
for gnome.

Ofcourse the more complete the alternative implementations are of the
systemd services are, the better the Gnome experience can be for those
choosing gnome but not systemd. For example systemd-shim seems to be an
effort in this direction.


None of this is rocket science and none of this requires a pre-emptive
resolution on the TC side to decide what dependencies are generally
allowed (which probably would do more harm then good). Advise, is
ofcourse always welcome, but lets try and solve technical problems with
technical solutions rather then politics as in the end that's what we
tend to do best.

> Another reason for urgency is that there was actually consensus
> in the TC that Debian should multiple init systems.[2] That was
> completely lost in all the "Debian chooses systemd" headlines that
> followed a widely published resolution that was only about the default 
> and didn't cover that aspect.
> 
> Or perhaps that's no longer urgent, since the "Debian chooses systemd"
> headlines are already in everyone's head, and a later statement
> "but we also support other init systems" would anyway not make it
> into the news.

I think for all of us that actually had a stake in this discussion, it
has been more then painful enough so I doubt we'll forget that aspect.
If you're aiming for headlines, i doubt re-affirming support for
multiple systems will make much of a dent there.


-- 
Sjoerd Simons 


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392246961.18727.44.ca...@dusk.luon.net

Bug#727708: init system coupling etc.

[Richard Hartmann]

On Wed, Feb 12, 2014 at 6:56 PM, Russ Allbery  wrote:

> Please note that I personally am currently leaning towards voting Keith's
> proposal above the one that I'm proposing in this message for the reasons
> that he states in that message.

Given the overall heat in the prior debate, I can see value in basic
guidance without forcing anybody's hand. As Ian notes, these are
exceptional times.


> I'm also happy to consider amendments to this text along the lines of
> Steve's proposed language elsewhere in the thread.

I think Sam had a worthwhile idea: Avoid normative language in
preference of observative language. To quote Debian's favorite card
game: "It has been observed that..."


  Under section 6.1.5 of the Debian Constitution, the Technical Committee
  observes the following:

  Having a default init system means that all normal packages support
  it. Packages with a very specific purpose can deviate from this.
  Examples include alternative init system implementations,
  special-use packages such as managers for non-default init systems,
  and cooperating groups of packages intended for use with non-default
  init systems.
  Packages lacking support for the default init system may be unusable
  on most Debian systems, thus limiting their adoption.

  Debian tries to offer choice whenever possible. Choice can be increased
  by adding or maintaining support for alternate init systems. Two
  possible ways for package maintainers to achieve this goal are to
  implement support themselves, or to apply patches provided to them.
  It is important that platform-independent packages support all default
  init systems on all Debian platforms.

  Smooth upgrades from stable to stable+1 are rightfully expected by
  Debian users. For upgrading from wheezy to jessie in particular,
  upgrades with both the old and new default init system running need
  to work. One good way to ensure smooth upgrades is to maintain and
  improve sysvinit support over the jessie lifecycle.
  sysvinit may not support all features of the default init system.
  This could result in degraded operation of some packages. Working
  around or fixing this degradation provides a benefit to Debian users.

  jessie+1 is too far into the future to make useful observations about
  future requirements or package dependencies on specific init systems
  today.


Notes:
* I am unhappy with the tautology in the beginning; it reads very much
like "the default is the default"
* Russ' text reads generally smoother, my version is more cumbersome
* I deliberately avoided calling the default system by name, same as Russ
* You are more than welcome to use, re-use, or discard all of this; if
it's useful: good. If not, please simply ignore to keep S/N ratio high


Thanks,
Richard


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/cad77+gtmj5cv6kc0vrdvoopcqhq-7gtmgckq1yukdcwcfsa...@mail.gmail.com

Bug#727708: init system coupling etc.

[Christian Seiler]

Hi there,

Preface: I'm not involved with the Debian project directly other than as
a user. So while I personally have strong opinions when it comes to the
init system, so far I have just followed the debate because I didn't
feel it would be helpful to spam this bug with useless comments. That
said, I have thought about the coupling issue for quite a while now and
I firmly believe that the original L and T options are BOTH explicitly
harmful (in different ways). For this reason, I feel the need to express
my opinion on this subject. But after I have said my piece, unless there
is a need for clarification on my side, I will walk back to the
sidelines and continue to watch.



First of all, I do think there are legitimate concerns that lead to both
the T and L options. On the one hand, the L text is clearly motivated by
the worry that if a huge part of the Debian ecosystem (*cough* GNOME
*cough*) suddenly depends on a specific init system (*cough* systemd
*cough*) then the commitment to multiple init systems gets reduced to a
farce. People might disagree about whether this is in reality going to
become a problem, but I think the concern is legitimate. On the other
hand, the T text seems to be motivated by the wish to not hamper
progress when it comes to software, that the Debian project should not
hold software back because of some ideological reasons.


That said, I think both texts are problematic: L being far to extreme in
its scope and T being far too toothless in the side sentence about
"encouragement" when it comes to support for other init systems.


The problem I have in this discussion is that only a few cases have been
picked apart in detail, but the wider implications of these options have
been mentioned in passing at best. So for this reason, I'd like to
propose several different scenarios where the coupling question applies,
so that the consequences of language used in the coupling question
becomes clear. So let me draw up a couple of scenarios:



(A) Someone writes a GUI for managing systemd that has the goal of
providing access to as many features as possible, so that it really is
tightly coupled to systemd in that sense. There is no way this could
realistically be ported to other init systems. (Although a different
software for e.g. upstart could be affected in the same way.)


(B) Someone writes a GUI for accessing journald files on the hard drive.


(C) Someone writes some kind of framework that depends on advanced
systemd features, such as systemd-nspawn, to provide a novel technical
solution. This software is new and not yet widely adopted. (Somewhere in
the original discussion before all of the ballots, somebody mentioned
something akin to this, I just don't feel it makes sense to invest the
time to dig that up.)


(D) Someone writes a daemon that currently only works with systemd, but
a patch for including sysvinit and upstrart support is literally only 5
lines of code.


(E) GNOME depends on logind interfaces and there is not working
alternative logind (>=205) implementation available.


(F) GNOME depends on logind interfaces and somebody stepped up and
created a logind implementation for other init systems.


(G) GNOME starts to depend on systemd as pid1 irrespective of logind.


(H) Some software part of the default install set (which currently does
not include GNOME but might again in the future) depends on systemd as
PID1, either directly (see G) or indirectly via logind with no
alternative implementation (see E).



I think that both "L" and "T" options have undesirable consequences. (To
clarify: I consider some of these to be undesirable for Jessie, not
necessarily for later releases.)

Let me start with "T":

 - Most serious case (H): If any software in the default install set
   depends on systemd, then this IMHO creates the de-facto situation
   that there really only is systemd support. Because if you can't
   switch the init system if you have a default set of software
   installed, saying that you support multiple init systems is a farce.

   Therefore, I definitely think that any resolution by the TC should
   include language that says that any software in the default install
   set should work with ALL supported init systems (with degraded
   operation being possible).

   So in the case of GNOME, if it continues to depend on logind (likely)
   and there doesn't happen to be a logind implementation that works
   with all the other init systems (unknown), then that should
   definitely disqualify GNOME from being made default desktop again.
   (OTOH, if there IS an alternative logind implementation at the point
   where this is decided, this doesn't stand in the way of GNOME
   becoming the default desktop again, but obviously it will also not
   make GNOME automatically the default desktop, that will depend on
   other things. ;-))

 - Case (G): I don't think this is likely to happen for Jessie, but I
   do think this should be addressed. Since GNOME is one of the major

Bug#727708: init system coupling etc.

[Ian Jackson]

Lucas Nussbaum writes ("Bug#727708: init system coupling etc."):
> If you really want to have that discussion now, rather than wait for
> actual, concrete problems to discuss, I'd suggest that you build a few
> hypothetical scenarios, and discuss them. And then build a resolution
> that represents the aggregated opinions on those few hypothetical
> scenarios.

I think there is one key hypothetical scenario, and it is the one
alluded to in Adrian Bunk's recent message:

] One of the Debian GNOME maintainers has stated in this discussion[1]:
]
]>  But there are no realistic solutions for having GNOME support multiple 
]>   init systems in jessie.
]
] Whether that's actually true is another question, but a maintainer 
] speaking like this clearly shows that it is not only a theoretical
] question.

I don't find Sjoerd Simons's comments very reassuring.  In the context
of the whole discussion I think Adrian's interpretation is much more
likely to reflect the true sentiment.

The question in that context is this: if GNOME upstream say that GNOME
will only work with systemd, or the Debian GNOME maintainers say that
Debian's GNOME packages will only work with systemd, is that
acceptable ?

Do you think it would be better to deal with that hypothetical case
explicitly ?

> But I also don't really understand why there's a particular urgency
> for the TC to rule on that. Are there packages with tight coupling
> already in the archive?

AIUI GNOME in sid right now can't lock the screen unless you're using
systemd.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21244.44791.663070.679...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Keith Packard writes ("Bug#727708: init system coupling etc."):
> I agree with you that this is an important issue which needs to be
> resolved within the Debian project. I also want to make it clear that I
> support the goal of having the project provide a clear policy statement
> about this issue in the short term.
> 
> The discussions held within the context of the default init bug were
> fruitful, and without rancor, which makes me hopeful that the project
> membership can drive this issue to consensus in the near future through
> the usual policy editing process. As such I'd like to amend this
> proposed ballot with an additional option:

I don't think this is likely but I can see why you would want to try
that.

>  * The TC chooses to not pass a resolution on this issue at the current time.
> 
> This is different from FD as it says the TC will not continue
> discussions on this issue, although it could well restart them if the
> people involved in the policy editing process come to an impasse. It's
> also different from 'T' in that it will allow us to revisit this in the
> future without needing to overturn a previous decision.

And it is different from FD in that if enough people outside the TC
feel that the issue needs to be decided now, it signals that the time
for them to propose a GR has come.

> Thank you for your consideration.

And thanks for engaging with the process in a constructive way.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21244.44919.747131.603...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> I propose the following text as an amendment to this option.  [...]

Thanks for your constructive contribution.  (As I'm sure you'll
understand, I don't agree with it but it is right that you propose
something you feel reflects your views.)

>  It would replace this text in its entirety, including the [GR
> rider] section.  (I don't see any need for or purpose served by
> cancelling technical advice to the project based on a GR outcome.

I agree.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21244.44936.271264.363...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Eugene Zhukov]

Ian Jackson  writes:
[...]
> I don't find Sjoerd Simons's comments very reassuring. In the context
> of the whole discussion I think Adrian's interpretation is much more
> likely to reflect the true sentiment.

I wouldn't give Adrian too much credit. Please read some other emails
between him and fellow developers in this bug. Especially [0].

[0] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=727708#4652


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/capqgmfjfvwywf-y+t0-fhxya5pcxnuodkto1jfjxulhggc0...@mail.gmail.com

Bug#727708: init system coupling etc.

[Petr Baudis]

  Hi!

> AIUI GNOME in sid right now can't lock the screen unless you're using
> systemd.

  When I asked about this [0], I got one reply (by Bdale) saying that
a missing functionality like this is fine as long as there is no hard
dependency on systemd and things somehow load.  If your opinion is
different, that seems to underline that the resolution would have to
get quite concrete if useful.

  [0] https://lists.debian.org/debian-ctte/2014/01/msg00609.html


> The question in that context is this: if GNOME upstream say that GNOME
> will only work with systemd, or the Debian GNOME maintainers say that
> Debian's GNOME packages will only work with systemd, is that
> acceptable ?

  I'm a little confused about exactly what happens if that is "not
acceptable".  The only *effective* manifestation of "not acceptable"
I can think of is:

GNOME packages will be reverted to last version working without
systemd and GNOME maintainers prohibited from tracking upstream
until it works on systemd-less systems without major bugs.

Obviously(?), that doesn't seem to be too reasonable; based on my
observations, this doesn't seem to be in the general spirit of CTTE
resolutions.

  Instead, if CTTE is overriding a maintainer, the resolutions often
allow a NMU to fix the issue.  That would be reasonable here, but this
seems only sensible when there is actually something to upload to
resolve the issue.  Apparently, the work to make GNOME work without
systemd is not done yet, and is there a reason to believe NMU would
have to be done if/when there is a patch?


  In short, if you would like to ask the GNOME maintainers to do some
work, what is their incentive, what happens if they don't find time /
energy to do it?

  Thanks for clarifications,

Petr "Pasky" Baudis


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213164712.gd7...@machine.or.cz

Bug#727708: init system coupling etc.

[Noah Meyerhans]

On Wed, Feb 12, 2014 at 10:35:12PM +, Ian Jackson wrote:
> > >Software outside of an init system's implementation may not require
> > >a specific init system to be pid 1, although degraded operation is
> > >tolerable.
> > 
> > This is super vague. What does being "outside of an init system's
> > implementation" mean? What does "degraded operation" mean?
> 
> Yes.  I agree that it's vague.  I'm open to better and clearer
> suggestions.  When I wrote this I was hoping that the policy process
> would be able to refine the details but perhaps that's overoptimistic.

Might we be able define "degraded operation" in terms of BTS severities?
Packages MUST NOT experience Severity:important or greater buggy
behavior with alternate inits as pid 1, for example.

There's still a certain amount of subjectivity in identifying bug
severities, but we've got a lot of experience with them and generally
manage to agree on them. Defining such coupling in terms of BTS
severities is also nice because it makes it easy for us to use our
existing infrastructure to track, over time, how tightly coupled we
become with a particular init system.

noah



signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Ian Jackson]

Noah Meyerhans writes ("Bug#727708: init system coupling etc."):
> On Wed, Feb 12, 2014 at 10:35:12PM +, Ian Jackson wrote:
> > Yes.  I agree that it's vague.  I'm open to better and clearer
> > suggestions.  When I wrote this I was hoping that the policy process
> > would be able to refine the details but perhaps that's overoptimistic.
> 
> Might we be able define "degraded operation" in terms of BTS severities?
> Packages MUST NOT experience Severity:important or greater buggy
> behavior with alternate inits as pid 1, for example.

I suppose what I mean is that a problem which occurs due to "wrong"
init system is a real problem and should not be reduced in severity or
excused on the grounds that the particular init system is defined as
"required" (whether via a dependency or otherwise).

So if the degraded operation amounts to a missing feature (a bug of
wishlist severity), then that's a bug of wishlist severity (and might
be closed or tagged "wontfix").

If the degraded operation amounts to a plain bug (ie bug of normal
severity), then that's a bug of normal severity.  Packages with bugs,
even regressions, are of course routinely uploaded and released.
Whether to do so is a tradeoff which we leave the maintainer to
consider.

If the degraded operation amounts to a bug of RC severity, then that's
a bug of RC severity and the new version of the requiring package
should be blocked from transitioning to testing, or being released,
until the problem is fixed, or at least worked around so that it is no
longer RC.

Is this a suitable approach ?  If so then perhaps I should clarify my
proposed wording.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21245.2196.366983.826...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Colin Watson]

On Wed, Feb 12, 2014 at 09:56:42AM -0800, Russ Allbery wrote:
> I propose the following text as an amendment to this option.  It would
> replace this text in its entirety, including the [GR rider] section.  (I
> don't see any need for or purpose served by cancelling technical advice to
> the project based on a GR outcome.  All the members of the project are, I
> think, capable of using their own judgement to resolve technical advice
> with the substance of a GR, and technical advice is by definition not
> binding.  Plus, I think this is a basically sensible thing to say
> regardless of the chosen init system.)
> 
> Please note that I personally am currently leaning towards voting Keith's
> proposal above the one that I'm proposing in this message for the reasons
> that he states in that message.  But I think it's useful to have a
> statement on the ballot so that it can be ranked, since it may be a
> compromise position between deferring to the Policy process and Ian's
> proposal.

I think the detail of this option is a good approach; I'd like to see it
on the ballot, and I would currently be inclined to rank something like
this first.

I'm currently undecided about whether I prefer the approach of setting
technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
mind all the process discussions we've had, I can see that it might be
better to take the approach of offering technical advice rather than
getting (re-)embroiled in a distracting procedural dispute about whether
the Constitution entitles us to rule in advance on a subject that hasn't
clearly been asked of us by some other first-responding maintainer.  If
we can establish an advice position that has strong consensus in the
committee (even if not necessarily at first place on this ballot, given
that some committee members would prefer to set technical policy in
advance), then we can always come back to it for reference later if we
should find it necessary to overrule maintainers.

Ian, you said that you don't agree with this amendment.  I am guessing
based on your previous statements that you mainly disagree with the
force of it, rather than the substance, but I'm cautious of making
unwarranted inferences or putting words in your mouth.  Is this
accurate?  I think it would be helpful if we had as much substantive
common ground between the ballot options as possible.

> Packages should normally support the default Linux init system.  There
> are some exceptional cases where lack of support for the default init
> system may be appropriate, such as alternative init system
> implementations, special-use packages such as managers for non-default
> init systems, and cooperating groups of packages intended for use with
> non-default init systems.  However, package maintainers should be
> aware that a requirement for a non-default init system will mean the
> package will be unusable for most Debian users and should normally be
> avoided.

Some of the details found here would be helpful in L too, and I think
they should be common ground.  In particular, several people have noted
the case of something like separate management utilities for a
particular init system which make use of advanced details of its
implementation.  I personally have no quarrel with these as long as
users of other init systems are not required to install them in order to
(say) use their desktop environment and keep it updated in a reasonable
way.  But it's not clear that these are part of the init system's
implementation, and I would probably argue that they aren't, especially
if (as they might well be) they are maintained by entirely different
people.

To start with, I therefore propose the following amendment to L.  I
think it is no weaker except in ways that we would agree were in fact OK
if we found ourselves needing to rule on them specifically, and this
addresses points that people have raised here.  The first paragraph of
the "loose coupling" section is replaced by the following:

  In general, software may not require a specific init system to be pid
  1, although degraded operation is tolerable.  The exceptions to this
  are as follows:

   * alternative init system implementations
   * special-use packages such as managers for init systems
   * cooperating groups of packages intended for use with specific init
 systems

  provided that these are not themselves required by other software
  whose main purpose is not the operation of a specific init system.

  Maintainers are encouraged to accept technically sound patches
  to enable improved interoperation with various init systems.

(It took me three goes to draft this in a way I was happy with, so
perhaps more wordsmithing is needed.)

> For the jessie release, all packages that currently support being run
> under sysvinit should continue to support sysvinit unless there is no
> technically feasible way to do so.

"Technically feasible" is so dependent on inte

Bug#727708: init system coupling etc.

[Ian Jackson]

Colin Watson writes ("Bug#727708: init system coupling etc."):
> Ian, you said that you don't agree with this amendment.  I am guessing
> based on your previous statements that you mainly disagree with the
> force of it, rather than the substance, but I'm cautious of making
> unwarranted inferences or putting words in your mouth.  Is this
> accurate?  I think it would be helpful if we had as much substantive
> common ground between the ballot options as possible.

OK.  I will review it in more detail.

> To start with, I therefore propose the following amendment to L.  I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here.  The first paragraph of
> the "loose coupling" section is replaced by the following:
> 
>   In general, software may not require a specific init system to be pid
>   1, although degraded operation is tolerable.  The exceptions to this
>   are as follows:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
> 
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.

I think this is a good approach.  I accept this amendment.  Thank you.

> (It took me three goes to draft this in a way I was happy with, so
> perhaps more wordsmithing is needed.)

I'll have a go at that but I don't want to break it.

> I do expect to have some more thoughts on this, and I'd like to ask that
> we not rush to a vote while we're still actively throwing around
> interesting amendments.  I've had a cluster of complicated customer bugs
> to deal with at work and have been generally busy in the evenings as
> well, so I've not been able to get all the way through my thinking on
> this.  I would rather not have to vote FD again if it can be avoided in
> the discussion period.  On the other hand I can understand Ian's wish to
> put a time limit on this rather than it dragging on forever.  Would an
> extra week work for everyone?  I don't think too much in the way of
> irreversible changes will happen in unstable in that time.

I'm more worried about irreversible changes in the wider world, but
perhaps anything we do now is too late to overcome the "systemd wins
everywhere" headlines.

I do see that we are making progress, which I felt we weren't before.
I'm willing to wait.  So for the avoidance of any doubt, I'm going to
set a new planned-CFV of 2014-02-20 18:30 UTC.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21245.3655.835126.536...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Uwe Storbeck]

On Feb 12, Russ Allbery wrote:
> Packages should normally support the default Linux init system.
[..]
> Package maintainers are strongly encouraged to merge any contributions
> for support of init systems other than the Linux default, and to add
> that support themselves if they're willing and capable of doing so.

Assumed a package has (only) start scripts for sysvinit. This
satisfies "Packages should normally support the default Linux
init system" (using sysvinit compatibility mode).
Someone provides patches to add native support for upstart and
systemd, maybe to use advanced features like socket activation.
Following the above proposal the package maintainer is encouraged
to apply the patch for upstart (as an init system "other than the
Linux default"), but not the patch for systemd.

Wouldn't it be better to change that to something like "for
support of any init system"?

Uwe


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213182553.ga3...@ibr.ch

Bug#727708: init system coupling etc.

[Paul Hedderly]

On Thu, Feb 13, 2014 at 06:01:56PM +, Ian Jackson wrote:
> I suppose what I mean is that a problem which occurs due to "wrong"
> init system is a real problem and should not be reduced in severity or
> excused on the grounds that the particular init system is defined as
> "required" (whether via a dependency or otherwise).
> 
> So if the degraded operation amounts to a missing feature (a bug of
> wishlist severity), then that's a bug of wishlist severity (and might
> be closed or tagged "wontfix").
> 
> If the degraded operation amounts to a plain bug (ie bug of normal
> severity), then that's a bug of normal severity.  Packages with bugs,
> even regressions, are of course routinely uploaded and released.
> Whether to do so is a tradeoff which we leave the maintainer to
> consider.

If you consider a dependancy as a bug... then the next question might have to
be - who's is the bug. Is it the fault of the package or group of packages
such as GNOME needing a feature/api - or is it the fault of alternative
feature providers that they do not provide the facilities required - ie
the fault of the init system. 

Is innovation and progress a bug?
Or is stagnation a bug?
Surely the "bug" is with packages that do not provide what is needed (yet).

So in this case I would feel then that it could be considered a bug that OpenRC,
Upstart etc do not provide (yet) the features that GNOME need/want to depend
on. But there is hope for technical solutions to be found for those problems
as they arise - as systemd-shim shows. (Personally I think that package has an
exceedingly misleading name! Am I alone?)

> If the degraded operation amounts to a bug of RC severity, then that's
> a bug of RC severity and the new version of the requiring package
> should be blocked from transitioning to testing, or being released,
> until the problem is fixed, or at least worked around so that it is no
> longer RC.

So we should start raising bugs against sysvinit,openrc,upstart etc for any
features that systemd has that might be useful, but which are missing in
those respective packages?

There being more than one way to see this problem, I hope we can go the way
Keith has proposed: Now that the issue is clearly in focus for project
maintainers I would be very surprised if amicable technical resolutions
cannot be found as they are required.

IMHO the big issue for the project really was/is which is the default init
system for Jessie which for Jessie, and against which all packages must
fully work. Potential GR aside, happily the work to focus on that target
can now commence in earnest.

Regards


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213182426.gg10...@wacka.mjr.org

Bug#727708: init system coupling etc.

[Ian Jackson]

Colin Watson writes ("Bug#727708: init system coupling etc."):
> To start with, I therefore propose the following amendment to L.  I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here.  The first paragraph of
> the "loose coupling" section is replaced by the following:
> 
>   In general, software may not require a specific init system to be pid
>   1, although degraded operation is tolerable.  The exceptions to this
>   are as follows:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
> 
>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.
> 
>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.
> 
> (It took me three goes to draft this in a way I was happy with, so
> perhaps more wordsmithing is needed.)

In the spirit of my response to Noah Meyerhans:

In general, software may not require a specific init system to be
pid 1.  The exceptions to this are as follows:
  * alternative init system implementations
  * special-use packages such as managers for init systems
  * cooperating groups of packages intended for use with specific init
systems
   provided that these are not themselves required by other software
   whose main purpose is not the operation of a specific init system.

   Degraded operation with some init systems is tolerable, so long as
   the degradation is no worse than a tolerable bug.  So the lack of
   a particular init system does not excuse a bug nor reduce its
   severity; but conversely, nor is a bug more serious simply because
   it is an incompatibility of some software with some init
   system(s).

Is this a clearer line to draw ?

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21245.5153.287086.351...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Andreas Barth]

* Colin Watson (cjwat...@debian.org) [140213 19:09]:
> To start with, I therefore propose the following amendment to L.  I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here.  The first paragraph of
> the "loose coupling" section is replaced by the following:
> 
>   In general, software may not require a specific init system to be pid
>   1, although degraded operation is tolerable.  The exceptions to this
>   are as follows:
> 
>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems
I'm not sure if this already covers the case of glue-packages, or if
we need to cover them (i.e. for a package foo, it's ok, if foo depends
on foo-sysv | foo-systemd | foo-upstart | foo-openrc, and each of
those four depends on a specific init system).


>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.

I think we agree that "required" doesn't involve cases where such a
package is just one of a different set of packages which fulfils that
requirement (via virtual packages or alternatives).


> Russ, can you give an example of a package that currently supports
> sysvinit where you would be happy that it might stop supporting it for
> jessie due to a lack of technical feasibility?

If this is advice, I think we can drop that part (for a decision that
might be different, and an indication that it might be possible that
there are exceptions might be appropriate).



Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213195644.gf16...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 13, 2014 at 08:56:44PM +0100, Andreas Barth wrote:
> * Colin Watson (cjwat...@debian.org) [140213 19:09]:
> > To start with, I therefore propose the following amendment to L.  I
> > think it is no weaker except in ways that we would agree were in fact OK
> > if we found ourselves needing to rule on them specifically, and this
> > addresses points that people have raised here.  The first paragraph of
> > the "loose coupling" section is replaced by the following:
> > 
> >   In general, software may not require a specific init system to be pid
> >   1, although degraded operation is tolerable.  The exceptions to this
> >   are as follows:
> > 
> >* alternative init system implementations
> >* special-use packages such as managers for init systems
> >* cooperating groups of packages intended for use with specific init
> >  systems
> 
> I'm not sure if this already covers the case of glue-packages, or if
> we need to cover them (i.e. for a package foo, it's ok, if foo depends
> on foo-sysv | foo-systemd | foo-upstart | foo-openrc, and each of
> those four depends on a specific init system).

I think this class of problem is handled by saying "software" rather
than "packages", much as we're saying "requires" rather than "depends
on"; I generally like Ian's approach of not trying to overspecify here.
If people feel this is unclear then maybe we need some kind of
for-avoidance-of-doubt rubric though.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213202508.ga31...@riva.ucam.org

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson  writes:

> I don't think this is likely but I can see why you would want to try
> that.

Thanks. Being new to the TC, I may feel more reluctant to exercise it's
process than people more familiar to the role.

> And it is different from FD in that if enough people outside the TC
> feel that the issue needs to be decided now, it signals that the time
> for them to propose a GR has come.

While I would lean towards not supporting a GR at this time, I agree
that having one not occur in parallel with a matching TC discussion
would probably work out better.

> And thanks for engaging with the process in a constructive way.

We'll make it work somehow.

-- 
keith.pack...@intel.com


pgpuueAnN6ot_.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Russ Allbery]

Colin Watson  writes:

> I'm currently undecided about whether I prefer the approach of setting
> technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
> mind all the process discussions we've had, I can see that it might be
> better to take the approach of offering technical advice rather than
> getting (re-)embroiled in a distracting procedural dispute about whether
> the Constitution entitles us to rule in advance on a subject that hasn't
> clearly been asked of us by some other first-responding maintainer.

I also think Keith's point that the normal process for setting Policy can
probably handle this is entirely correct.  Certainly, I don't think there
will be substantial difficulties hammering out a Policy change given
advice from the TC.  If there is, we can always deal with it at that
point.

> To start with, I therefore propose the following amendment to L.  I
> think it is no weaker except in ways that we would agree were in fact OK
> if we found ourselves needing to rule on them specifically, and this
> addresses points that people have raised here.  The first paragraph of
> the "loose coupling" section is replaced by the following:

>   In general, software may not require a specific init system to be pid
>   1, although degraded operation is tolerable.  The exceptions to this
>   are as follows:

>* alternative init system implementations
>* special-use packages such as managers for init systems
>* cooperating groups of packages intended for use with specific init
>  systems

>   provided that these are not themselves required by other software
>   whose main purpose is not the operation of a specific init system.

>   Maintainers are encouraged to accept technically sound patches
>   to enable improved interoperation with various init systems.

There's probably no chance that I will vote any version of L above FD, so
feel free to disregard this.  But I think this is begging for some sort of
definition of "specific."

As written, it seems like it either requires all packages in the archive
add runit configuration, since otherwise they're not supporting all init
systems available in Debian, or alternately that any package that provides
a runit configuration and an OpenRC configuration and depends on runit |
openrc is fine, since it doesn't depend on "a" specific init system (it
depends on one of two specific init systems).

I don't think either of those are what you intend here.  But I'm at a loss
as to what you *do* intend.  Explain it to me like I'm five?  :)

>> For the jessie release, all packages that currently support being run
>> under sysvinit should continue to support sysvinit unless there is no
>> technically feasible way to do so.

"packages" here should probably actually be "software" for all the reasons
discussed elsewhere.

> "Technically feasible" is so dependent on interpretation that I'm not
> sure whether it has enough real meaning.  My instinct is to borrow some
> of the "exceptional cases" language from an earlier paragraph.  On the
> other hand, "all packages that currently support being run under
> sysvinit" seems to mostly cover this well enough - it just takes me a
> couple of readings to get to it.  Does this sentence bother anyone else?
> Russ, can you give an example of a package that currently supports
> sysvinit where you would be happy that it might stop supporting it for
> jessie due to a lack of technical feasibility?

Yes: logind.  I think it should be fine to package a current version of
logind for Debian (meaning one that requires cgroups).  I don't think
logind is part of the init system implementation; it's just another
program, like udev, that's built from the systemd source package.  I don't
think it falls into any of the other exception cases.  I think it's quite
reasonable to package a current logind for those who want to use it, even
though, by requiring cgroups, it currently only works with a corresponding
version of systemd as init.  (Note that packaging it and having other
packages depend on it are distinct acts with separate implications.)

My understanding of the expected situation for jessie is that either
another cgroups implementation that works under sysvinit will be available
or someone will package logind 204 in a way that works with sysvinit.
Given that, it will be technically feasible for GNOME to depend on a
logind solution that doesn't require systemd.  Therefore, this advice says
that GNOME should not depend on systemd as init.  (This is all totally
obvious, of course, and I'm quite confident that the GNOME maintainers
don't need this advice to do the right thing, which is exactly why I will
probably be voting Keith's proposal first.)

But suppose that the alternative cgroups implementation doesn't
materialize.  That specific logind implementation then *would* depend on
systemd as init.  Does that mean that a logind that uses systemd cgroups
management is not permitted in Debian for the jess

Bug#727708: init system coupling etc.

[Russ Allbery]

Uwe Storbeck  writes:
> On Feb 12, Russ Allbery wrote:

>> Packages should normally support the default Linux init system.
> [..]
>> Package maintainers are strongly encouraged to merge any contributions
>> for support of init systems other than the Linux default, and to add
>> that support themselves if they're willing and capable of doing so.

> Assumed a package has (only) start scripts for sysvinit. This satisfies
> "Packages should normally support the default Linux init system" (using
> sysvinit compatibility mode).  Someone provides patches to add native
> support for upstart and systemd, maybe to use advanced features like
> socket activation.  Following the above proposal the package maintainer
> is encouraged to apply the patch for upstart (as an init system "other
> than the Linux default"), but not the patch for systemd.

> Wouldn't it be better to change that to something like "for support of
> any init system"?

Yes, that's much better.  Thanks!

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppmqtk4y@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Russ Allbery]

Christian Seiler  writes:

> On the other hand, the T text seems to be motivated by the wish to not
> hamper progress when it comes to software, that the Debian project
> should not hold software back because of some ideological reasons.

Well, the T language wasn't written by me, but I should clarify that's not
what I'm trying to say in my proposals.  I think Debian should do lots of
things for ideological reasons.  One of the pieces of Debian ideology that
matters a great deal to me is that we should trust our package maintainers
to choose how to package the software they maintain, and trust their
judgement about the approach that provides the best, most high-quality,
and most integrated experience for our users.

In other words, what I want to do is defer to package maintainers, who
are, after all, experts in the packaging of their software, to make good
decisions.  The TC should only get involved where there are irreconcilable
conflicts about how to do this, or when the project asks us for guidance
on how to achieve distribution-wide integration.

I feel like an argument could be made that the project has asked us for
advice on this (although I think a good argument could be made that the
project has *not*, which is Keith's point).  I'm trying to express that
advice while continuing to recognize and respect the fact that Debian
defers, in nearly every case, to the informed technical judgement of the
packager or packaging team, and generally tries to address most conflicts
by enabling the parallel packaging of software with different approaches
rather than choosing a single winner and rejecting all other "competing"
packages.  I'm also trying to respect the core foundational value of
Debian that volunteers get to work on what they choose to work on, and no
body in Debian has the authority to order people around.

I found your specific cases a useful clarifying exercise to lay out how I
think about this, so let me respond to each of them:

> (A) Someone writes a GUI for managing systemd that has the goal of
> providing access to as many features as possible, so that it really is
> tightly coupled to systemd in that sense. There is no way this could
> realistically be ported to other init systems. (Although a different
> software for e.g. upstart could be affected in the same way.)

This clearly should depend on systemd and should be allowed.

> (B) Someone writes a GUI for accessing journald files on the hard drive.

Depending on how this is written, it may depend on the package providing
journalctl or it may depend on some shared library that implements the
journal reading code, or it might even have no dependencies at all if it
implements the journal reading code itself.

> (C) Someone writes some kind of framework that depends on advanced
> systemd features, such as systemd-nspawn, to provide a novel technical
> solution. This software is new and not yet widely adopted. (Somewhere in
> the original discussion before all of the ballots, somebody mentioned
> something akin to this, I just don't feel it makes sense to invest the
> time to dig that up.)

This clearly should depend on systemd and should be allowed.

> (D) Someone writes a daemon that currently only works with systemd, but
> a patch for including sysvinit and upstrart support is literally only 5
> lines of code.

Assuming that this is a new package not previously in Debian, and after
systemd has become the default init system, I think it should be fine to
introduce this package with a dependency on systemd until such time as
someone actually writes and tests that patch.  Once that patch is written
and tested and submitted, the maintainer should incorporate it and drop
the dependency.  (Constitutionally, I don't think the TC should require
maintainers to do this in advance, but if this actually got escalated all
the way to the TC as a maintainer override, something that I really hope
would never happen and I see no reason to believe would happen, I would be
baffled by why the maintainer wouldn't include such support.)

> (E) GNOME depends on logind interfaces and there is not working
> alternative logind (>=205) implementation available.

(I don't know of any reason why GNOME would specifically need to depend on
a post-205 logind at this point, so I'm replying to this without the
parenthetical.)

I think this should be fine.  But this is a controversial case that we
have strong reasons to believe won't actually arise, so it's not clear
whether there's any need to argue about my position on it.

> (F) GNOME depends on logind interfaces and somebody stepped up and
> created a logind implementation for other init systems.

In this case, I think GNOME should allow either implementation to satisfy
its dependency.  I think that's uncontroversial across the board,
including with the GNOME maintainers.

> (G) GNOME starts to depend on systemd as pid1 irrespective of logind.

There doesn't seem to be any technical reason why this would be necessary,

Bug#727708: init system coupling etc.

[Josselin Mouette]

Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
> > (B) Someone writes a GUI for accessing journald files on the hard drive.
> 
> Depending on how this is written, it may depend on the package providing
> journalctl or it may depend on some shared library that implements the
> journal reading code, or it might even have no dependencies at all if it
> implements the journal reading code itself.

This is not a hypothetical case. It exists, and it uses journald
directly. The software will not start if systemd is not PID 1. Note that
this is part of what we’d like to put in the gnome metapackage, so
forbidding this has real impact on real packages for jessie.

> > (E) GNOME depends on logind interfaces and there is not working
> > alternative logind (>=205) implementation available.
> 
> (I don't know of any reason why GNOME would specifically need to depend on
> a post-205 logind at this point, so I'm replying to this without the
> parenthetical.)

This will certainly happen one day or another, but probably not for
jessie.

This (not isolated) case raises the point of package-level management of
non-library interfaces, with versions. We might need to set a policy on
this kind of cases. For example, should we generalize situations such
as:
* systemd-sysv Provides: systemd204, systemd207, … 
* foo Depends: systemd-sysv (>= 204) | systemd204

> > (F) GNOME depends on logind interfaces and somebody stepped up and
> > created a logind implementation for other init systems.
> 
> In this case, I think GNOME should allow either implementation to satisfy
> its dependency.  I think that's uncontroversial across the board,
> including with the GNOME maintainers.

This is indeed uncontroversial, except for the part that the non-systemd
case would be unsupported from the GNOME side.

I’m just not seeing this happening (see at the bottom).

> It's possible that, in the long, long run, GNOME will want to depend on
> systemd to use systemd for session management, but it's already been clear
> on this thread that this won't happen for jessie, and it's not at all
> clear whether this will ever be necessary or whether there will always be
> a fallback available.  It is obvious, at least as I understand it, that
> this won't be necessary or something anyone is considering for jessie.

It has already been made clear that this WILL happen for jessie, but
that a fallback (either in the same package or another one) can be made
available.

> We have one specific issue around logind that is likely to affect GNOME
> and KDE and possibly others, and we've talked about the solutions in
> detail and Steve is confident that we can solve this issue for sysvinit
> for jessie.

The only available solution so far involves keeping a systemd 204
package, which will not happen. With systemd as the default init system,
the systemd maintainers will try to have the latest version integrated.

So either Steve and his cronies commit to maintain a separate systemd204
package (with all the switching issues that scenario involves), or they
deliver their so-far vaporware to work over systemd >= 205. Or it just
doesn’t work, which is what will probably happen.

In all cases, it is unacceptable to put the burden of implementing
logind on non-systemd systems on maintainers of packages that just need
the logind interfaces. If it is not available, software such as gdm3
will depend, directly or indirectly, on systemd as PID 1, and that will
be all.

(For non-Linux ports, the old ConsoleKit code will be enabled instead,
but users should not expect this to work at all.)

-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392369156.26492.317.camel@dsp0698014

Bug#727708: init system coupling etc.

[Ian Jackson]

Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> In all cases, it is unacceptable to put the burden of implementing
> logind on non-systemd systems on maintainers of packages that just need
> the logind interfaces. If it is not available, software such as gdm3
> will depend, directly or indirectly, on systemd as PID 1, and that will
> be all.

Firstly, I think the scenario where the required integration work is
not done is unlikely.  But in that scenario, we have two choices:
 (a) Effectively, drop all init systems other than systemd
 (b) Effectively, drop GNOME

Of these, (b) is IMO clearly preferable.  Our downstreams can
straightforwardly provide a more specific Debian derivative which runs
GNOME and (only) systemd.  Asking our downstreams to reintroduce
support for a non-systemd init system is not feasible.

With (a) the only option for people who didn't want systemd would be
to either fork the whole of the Debian project and declare themselves
a new upstream for all of what Debian now does, or to abandon Debian
and its derivatives altogether.

With (b) people who want GNOME and systemd can do that work as a
Debian derivative; it is not necessary to fork the whole project.

The doomsday scenario of choosing between (a) and (b) becomes less
likely if we make it clear how bad it would be.  We need to provide
appropriate backpressure to encourage upstream decisions that support
the continued freedom of our users.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21246.7964.438896.80...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ansgar Burchardt]

Ian Jackson  writes:
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME
>
> Of these, (b) is IMO clearly preferable.

Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
plans to depend on logind... And it sounds like a really brillant idea
to drop all of them to keep ChaosEsque Team happy with Debian.

Ansgar


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny9kddj@deep-thought.43-1.org

Bug#727708: init system coupling etc.

[Josselin Mouette]

Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit : 
> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > In all cases, it is unacceptable to put the burden of implementing
> > logind on non-systemd systems on maintainers of packages that just need
> > the logind interfaces. If it is not available, software such as gdm3
> > will depend, directly or indirectly, on systemd as PID 1, and that will
> > be all.
> 
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME

This looks very much like a false dichotomy to me.

You can have (c) GNOME depends on systemd.
Same for KDE and Xfce, BTW, since they are going in the same direction.

Desktop environments are not the only pieces of software in Debian.
Having them depend on systemd doesn’t prevent you from using other init
systems on machines that don’t have them installed.

> The doomsday scenario of choosing between (a) and (b) becomes less
> likely if we make it clear how bad it would be.  We need to provide
> appropriate backpressure to encourage upstream decisions that support
> the continued freedom of our users.

I don’t see how (c) looks bad. What’s the problem of limiting the scope
of non-default init systems? It’s not as if we will want the same level
of support for them than we want for the default init system.

In all cases, this situation happening or not is the result of the work
of people not interested in logind nor in desktop environments. Having
the decision to keep packages in Debian depend on the work of unrelated
people is preposterous.

Cheers,
-- 
 .''`.Josselin Mouette
: :' :
`. `'
  `-


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392388301.26492.372.camel@dsp0698014

Bug#727708: init system coupling etc.

[Andres Freund]

On 2014-02-14 13:50:20 +, Ian Jackson wrote:
> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > In all cases, it is unacceptable to put the burden of implementing
> > logind on non-systemd systems on maintainers of packages that just need
> > the logind interfaces. If it is not available, software such as gdm3
> > will depend, directly or indirectly, on systemd as PID 1, and that will
> > be all.
> 
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME
> 
> Of these, (b) is IMO clearly preferable.  Our downstreams can
> straightforwardly provide a more specific Debian derivative which runs
> GNOME and (only) systemd.  Asking our downstreams to reintroduce
> support for a non-systemd init system is not feasible.

> With (b) people who want GNOME and systemd can do that work as a
> Debian derivative; it is not necessary to fork the whole project.

I don't think b) would have any upsides, even if it's only happening for
a short time:

a) Debian users would loose because the DE (gnome and some others) the
   use vanishes. We've seen how happy changes around that makes them,
   and how vocal they can get. Surely entirely removing a DE entirely
   makes them even more unhappy than substantive change.
b) Debian would loose users.
c) downstreams would suffer, because they now would need to package
   $software independently from debian. Collaboration without a common
   upstream is hard.
d) Parties wanting to port/test a piece of software to work without
   systemd, suddenly need to care about packaging, before their real
   work can start. Individual developers maybe can get by using source
   code checkouts and compiling everything themselves, but testers
   surely not.
e) Parties wanting to implement alternatives to systemd's logind, cgroup
   manager have less software to test.

Given those points the only value in suggesting that route is in being a
threat gesture against some unspecified party. I think such a gesture is
of questionable morality, but even worse, I think it runs counter to
your goals of having most software run independently of the init
system.
I don't see this helping the freedom of debian's users, rather the
contrary.

I think it makes much more sense to generate policy or a TC statement,
that suggests that packagers should apply reasonable patches to help
portability (just like they are already asked for porting software to
some different linux or other supported architecture). And, quite
importantly, try to streamline the process of dealing with escalations
to the TC to determine whether a patch is reasonable. If that takes half
a year every now and then most people will just give up.

Regards,

Andres Freund


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214152153.go4...@awork2.anarazel.de

Bug#727708: init system coupling etc.

[Ian Jackson]

Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
> plans to depend on logind...

logind is a red herring because AIUI we already have a technical
solution to that.  The problem is other things that might be in the
pipeline.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21246.14922.187282.667...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Ian Jackson writes ("Bug#727708: init system coupling etc."):
> In the spirit of my response to Noah Meyerhans:
> 
> In general, software may not require a specific init system to be
> pid 1.  The exceptions to this are as follows:
>   * alternative init system implementations
>   * special-use packages such as managers for init systems
>   * cooperating groups of packages intended for use with specific init
>   systems
>provided that these are not themselves required by other software
>whose main purpose is not the operation of a specific init system.
> 
>Degraded operation with some init systems is tolerable, so long as
>the degradation is no worse than a tolerable bug.  So the lack of
>a particular init system does not excuse a bug nor reduce its
>severity; but conversely, nor is a bug more serious simply because
>it is an incompatibility of some software with some init
>system(s).
> 
> Is this a clearer line to draw ?

I'd appreciate feedback from other TC members on this wording.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21246.15103.851155.370...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> Le jeudi 13 février 2014 à 23:47 -0800, Russ Allbery a écrit : 
> > Depending on how this is written, it may depend on the package providing
> > journalctl or it may depend on some shared library that implements the
> > journal reading code, or it might even have no dependencies at all if it
> > implements the journal reading code itself.
> 
> This is not a hypothetical case. It exists, and it uses journald
> directly. The software will not start if systemd is not PID 1.

This is covered by the exception that Colin drafted:

  In general, software may not require a specific init system to be pid
  1, although degraded operation is tolerable.  The exceptions to this
  are as follows:

   * alternative init system implementations
   * special-use packages such as managers for init systems
   * cooperating groups of packages intended for use with specific init
 systems

  provided that these are not themselves required by other software
  whose main purpose is not the operation of a specific init system.

>   Note that
> this is part of what we’d like to put in the gnome metapackage, so
> forbidding this has real impact on real packages for jessie.

What is pulled in by the gnome metapackage is a different issue.  My
draft talks about "software", not "packages", quite deliberately.
There isn't any distinct sofware in the gnome metapackage.  Indeed the
whole purpose of talking about "software" is so that metapackages,
glue packages ("foobar-runit"), and so forth, aren't caught by this
restriction.

Rather, the purpose of a metapackage is to arrange that the right
combination of software is installed.  So I don't think my proposed
wording prevents the gnome metapackage from pulling in systemd in this
way.

Whether the gnome metapackage should pull in systemd like this is
rather a different question.  It is more related to detailed questions
of the desirable behaviour during upgrades etc.  We discussed these in
some detail in the case of gnome -> network-manager.  I don't think we
need to address the metapackage point at this stage although I imagine
the TC may be asked about it.

Ian.


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21246.14950.903452.153...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Josh Triplett]

Ian Jackson wrote:
> I suppose what I mean is that a problem which occurs due to "wrong"
> init system is a real problem and should not be reduced in severity or
> excused on the grounds that the particular init system is defined as
> "required" (whether via a dependency or otherwise).
> 
> So if the degraded operation amounts to a missing feature (a bug of
> wishlist severity), then that's a bug of wishlist severity (and might
> be closed or tagged "wontfix").
> 
> If the degraded operation amounts to a plain bug (ie bug of normal
> severity), then that's a bug of normal severity.  Packages with bugs,
> even regressions, are of course routinely uploaded and released.
> Whether to do so is a tradeoff which we leave the maintainer to
> consider.
> 
> If the degraded operation amounts to a bug of RC severity, then that's
> a bug of RC severity and the new version of the requiring package
> should be blocked from transitioning to testing, or being released,
> until the problem is fixed, or at least worked around so that it is no
> longer RC.
> 
> Is this a suitable approach ?  If so then perhaps I should clarify my
> proposed wording.

This approach does solve one problem present in previous proposals, by
clarifying that a bug does not become any *more* severe just because it
involves init systems.  However, there are still two notable problems
this doesn't address.

First, on which init systems?.  Everything in Debian that provides
/sbin/init, no matter its capabilities or lack thereof?  Or some subset
of those implementations, in which case what are the selection criteria
for that subset?

Second, what makes init systems so wildly different from anything else
in Debian that the usual principles don't apply?  For any other package,
"doesn't work when its dependencies are replaced" is a wishlist bug.
Such bugs are often fixed, especially when a patch is supplied, but that
doesn't make them any more than wishlist, even though "doesn't work"
would be RC if the package's dependencies are satisfied.  That's true
even when the dependencies and their alternatives are packages that
can't coexist on the same running system.

As far as I can tell, the only difference is one of scale: systemd is
poised to provide functionality that far more packages want and might
benefit from depending on, and thus the fear that it will become
irreplaceable is higher.  Nonetheless, this still seems like something
that can be handled naturally.  People who want to support alternative
init systems can continue to do so; absolutely nothing is stopping them.
As long as that work remains tractable and people want to do it, it'll
find a way to happen; Debian developers are too good at cooperating with
each other for that not to work out.  If the work to support any
particular init system across all packages in the archive ever becomes
overwhelming and insurmountable, *that means something*.

It makes sense to ensure that developers or supporters of alternate init
systems can expect a reasonable reception for work they've done to make
packages work with their init system.  (I don't see any obvious reason
to expect that won't already happen, but it's certainly reasonable to
debate how best to achieve *that* goal.)  However, this proposal instead
suggests that if that work hasn't been done yet by anyone, something has
gone horribly wrong and must be fixed, rather than that a wishlist bug
exists and a patch would sure be nice.

Does a proposal phrasing exist that would satisfy the concerns
motivating this one, addressing the goal of supporting contribution of
support for alternate init systems, without making it a bug for the
maintainer of every package to do the work themselves?  Or is it the
intentional aim of this proposal to force package maintainers to do the
work of supporting all init systems themselves or face an RC bug?

(As an aside, while it wouldn't necessarily do everything you want out
of this proposal, I wouldn't be surprised if there's support from the TC
for a proposal of "maintain sysvinit compatibility through jessie, and
support smooth upgrades", which ought to address the concerns that are
motivating your urgency in addressing this issue.  Passing such a
resolution would then allow for a more prolonged consideration of how to
handle things post-jessie, as well as consideration of whether existing
cooperative processes in Debian might be able to handle this isue given
the time.  Any particular reason *not* to do that?)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214154617.GB20652@leaf

Bug#727708: init system coupling etc.

[Andres Freund]

On 2014-02-14 15:46:18 +, Ian Jackson wrote:
> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
> > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
> > plans to depend on logind...
> 
> logind is a red herring because AIUI we already have a technical
> solution to that.  The problem is other things that might be in the
> pipeline.

I am not so sure it's there. The current version runs without systemd
but doesn't support everything and more up2date versions don't run at
all. There's promise of more work in that direction, but that might be
influenced by Ubuntu seemingly also switching in the not too far away
future: http://www.markshuttleworth.com/archives/1316

Greetings,

Andres Freund


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214155934.gr4...@awork2.anarazel.de

Bug#727708: init system coupling etc.

[Ansgar Burchardt]

Hi,

Ian Jackson  writes:
> Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
>> Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
>> plans to depend on logind...
>
> logind is a red herring because AIUI we already have a technical
> solution to that.  The problem is other things that might be in the
> pipeline.

But even the suggested (and not yet existing) solution is very likely
not a long-term solution given Canonical switches to systemd[1]. It
might still work for Jessie, but I expect it to be abandoned later (and
do we really want to use it for Jessie in this case?).

I wouldn't expect someone else to take up maintaince either: this hasn't
happened for ConsoleKit after all. It is probably even less likely to
happen here as the suggested solution involves using parts of systemd
and people vehemently opposed to it are unlikely to work on it.

Ansgar

  [1] <http://www.markshuttleworth.com/archives/1316>


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87zjltisp0@deep-thought.43-1.org

Bug#727708: init system coupling etc.

[Russ Allbery]

Josselin Mouette  writes:
> Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit : 
>> Josselin Mouette writes ("Bug#727708: init system coupling etc."):

>>> In all cases, it is unacceptable to put the burden of implementing
>>> logind on non-systemd systems on maintainers of packages that just
>>> need the logind interfaces. If it is not available, software such as
>>> gdm3 will depend, directly or indirectly, on systemd as PID 1, and
>>> that will be all.

>> Firstly, I think the scenario where the required integration work is
>> not done is unlikely.  But in that scenario, we have two choices:
>>  (a) Effectively, drop all init systems other than systemd
>>  (b) Effectively, drop GNOME

> This looks very much like a false dichotomy to me.

> You can have (c) GNOME depends on systemd.
> Same for KDE and Xfce, BTW, since they are going in the same direction.

> Desktop environments are not the only pieces of software in Debian.
> Having them depend on systemd doesn’t prevent you from using other init
> systems on machines that don’t have them installed.

Exactly.

I somewhat disagree with Josselin in that I actually do think this is an
unlikely result and that, at least in the short term, people will step
forward and find an alternative solution.  I also don't think that
maintaining a 204-era logind in the archive for jessie if a cgroups fix
doesn't materialize is the worst thing that could happen, provided that
someone is willing to maintain it.

But I also don't agree with the idea that it's the end of the world if
GNOME depends on systemd.  There are a bunch of other DEs, and there are a
bunch of other uses for Debian systems other than running DEs.

That said, I again repeat that I question whether it's worth having this
argument when there are concrete steps people can take today to ensure
that it is an argument we don't have to have.

-- 
Russ Allbery (r...@debian.org)   <http://www.eyrie.org/~eagle/>


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87r47537tq@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Russ Allbery]

Josselin Mouette  writes:

> So either Steve and his cronies commit to maintain a separate systemd204
> package (with all the switching issues that scenario involves),

Hi Josselin,

I realize that passions are running high here, and there has been a great
deal of bad blood on both sides.  But regardless of the situation, this is
inappropriate language.  Talking about other people in Debian as if we're
part of rival camps, even if in the heat of the moment it feels like that,
is escalation and makes everything worse.  And using this sort of language
about other Debian contributors just damages our community without
accomplishing anything constructive.

I think you can make your point without referring to people with these
sorts of disparaging terms.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87mwht37k1@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Steve Langasek]

On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
> On 2014-02-14 15:46:18 +, Ian Jackson wrote:
> > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
> > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
> > > plans to depend on logind...

> > logind is a red herring because AIUI we already have a technical
> > solution to that.  The problem is other things that might be in the
> > pipeline.

> I am not so sure it's there. The current version runs without systemd
> but doesn't support everything

Based on what?  There is only one new interface in logind between v204 and
v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
telling me that this is a critical feature for desktops, that they won't run
correctly without?

> and more up2date versions don't run at all.  There's promise of more work
> in that direction, but that might be influenced by Ubuntu seemingly also
> switching in the not too far away future:
> http://www.markshuttleworth.com/archives/1316

Which says right in that blog entry that:

   We’ll certainly complete work to make the new logind work without systemd
   as pid 1.

Even supposing that GetUserByPID is critical for jessie, and even supposing
that Canonical did not finish the work to make logind work with cgmanager,
backporting this one interface to logind 204 will be trivial.  There is no
excuse at all for Debian getting the compatibility wrong in jessie.  (But an
awful lot of people who seem eager to make excuses for it.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Cory]

On 02/14/2014 12:14 PM, Steve Langasek wrote:

On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:

On 2014-02-14 15:46:18 +, Ian Jackson wrote:

Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):

Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
plans to depend on logind...

logind is a red herring because AIUI we already have a technical
solution to that.  The problem is other things that might be in the
pipeline.

I am not so sure it's there. The current version runs without systemd
but doesn't support everything

Based on what?  There is only one new interface in logind between v204 and
v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
telling me that this is a critical feature for desktops, that they won't run
correctly without?


and more up2date versions don't run at all.  There's promise of more work
in that direction, but that might be influenced by Ubuntu seemingly also
switching in the not too far away future:
http://www.markshuttleworth.com/archives/1316

Which says right in that blog entry that:

We’ll certainly complete work to make the new logind work without systemd
as pid 1.

Even supposing that GetUserByPID is critical for jessie, and even supposing
that Canonical did not finish the work to make logind work with cgmanager,
backporting this one interface to logind 204 will be trivial.  There is no
excuse at all for Debian getting the compatibility wrong in jessie.  (But an
awful lot of people who seem eager to make excuses for it.



So you guys are forking systemd?


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fe60d9.8060...@gmail.com

Bug#727708: init system coupling etc.

[Andres Freund]

On 2014-02-14 10:14:54 -0800, Steve Langasek wrote:
> On Fri, Feb 14, 2014 at 04:59:34PM +0100, Andres Freund wrote:
> > On 2014-02-14 15:46:18 +, Ian Jackson wrote:
> > > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
> > > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
> > > > plans to depend on logind...
>
> > > logind is a red herring because AIUI we already have a technical
> > > solution to that.  The problem is other things that might be in the
> > > pipeline.
>
> > I am not so sure it's there. The current version runs without systemd
> > but doesn't support everything
>
> Based on what?  There is only one new interface in logind between v204 and
> v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
> telling me that this is a critical feature for desktops, that they won't run
> correctly without?

Nono, that's not what I meant, sorry for being imprecise. Logind calls
out to systemd for shutting down. -shim now supports some of that, but
the last time I tried logind without systemd but just -shim didn't work
fully yet?

> > and more up2date versions don't run at all.  There's promise of more work
> > in that direction, but that might be influenced by Ubuntu seemingly also
> > switching in the not too far away future:
> > http://www.markshuttleworth.com/archives/1316
>
> Which says right in that blog entry that:
>
>We’ll certainly complete work to make the new logind work without systemd
>as pid 1.
>
> Even supposing that GetUserByPID is critical for jessie, and even supposing
> that Canonical did not finish the work to make logind work with cgmanager,
> backporting this one interface to logind 204 will be trivial.  There is no
> excuse at all for Debian getting the compatibility wrong in jessie.  (But an
> awful lot of people who seem eager to make excuses for it.

Please don't get me wrong. I don't think compatibility should be dropped
in the near future. It's just that Ian argued that gnome requiring
logind won't become a problem because of the current state of logind and
systemd-shim, and in consequence that forbidding dependencies on
interfaces provided only when systemd is present is unproblematic. I
don't think the current state warrants that.

I think there should be clear language, be it in policy or TC
resolution, to suggest that maintainers should accept compatibility
patches. But that's it.

Greetings,

Andres Freund


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214184932.ge20...@awork2.anarazel.de

Bug#727708: init system coupling etc.

[Steve Langasek]

On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:

> > > I am not so sure it's there. The current version runs without systemd
> > > but doesn't support everything

> > Based on what?  There is only one new interface in logind between v204 and
> > v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
> > telling me that this is a critical feature for desktops, that they won't run
> > correctly without?

> Nono, that's not what I meant, sorry for being imprecise. Logind calls
> out to systemd for shutting down. -shim now supports some of that, but
> the last time I tried logind without systemd but just -shim didn't work
> fully yet?

systemd-shim+logind is working fine in Ubuntu - and shutdown is pretty basic
functionality, that's expected to work.  I have recently seen some reports
(via IRC) that logind-based logout is not working from GNOME in unstable,
even when running systemd as PID1.  So there may be some bugs here, but I
have yet to receive any bug reports on the systemd-shim package pointing to
a problem with systemd-shim vs. systemd compatibility.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Cory]

On 02/14/2014 01:52 PM, Steve Langasek wrote:

On Fri, Feb 14, 2014 at 07:49:32PM +0100, Andres Freund wrote:


I am not so sure it's there. The current version runs without systemd
but doesn't support everything

Based on what?  There is only one new interface in logind between v204 and
v208, an 'org.freedesktop.login1.Manager.GetUserByPID' method.  Are you
telling me that this is a critical feature for desktops, that they won't run
correctly without?

Nono, that's not what I meant, sorry for being imprecise. Logind calls
out to systemd for shutting down. -shim now supports some of that, but
the last time I tried logind without systemd but just -shim didn't work
fully yet?

systemd-shim+logind is working fine in Ubuntu - and shutdown is pretty basic
functionality, that's expected to work.  I have recently seen some reports
(via IRC) that logind-based logout is not working from GNOME in unstable,
even when running systemd as PID1.  So there may be some bugs here, but I
have yet to receive any bug reports on the systemd-shim package pointing to
a problem with systemd-shim vs. systemd compatibility.

has any one reported this bug on systemd 205 and up also systemd 207 was 
a bug's fix release and systemd 204 is really dated i use systemd 204 in 
Debian testing but the ABI's have change with cgroup's for a newer 
systemd then 204.


but on the other hand Wayland support in Mutter relies on logind to 
handle VT switching this is a nice little rabbit hole that needs looked 
into Wayland-Mutter requires logind from a PID 1 systemd "critical 
feature" and Mir will too as well as they share some code no? down the 
road also systemd 208 has a major addition to logind for Wayland



--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/52fea1f7.8050...@gmail.com

Bug#727708: init system coupling etc.

[Andreas Barth]

* Russ Allbery (r...@debian.org) [140214 04:36]:
> Andreas Barth  writes:
> > * Russ Allbery (r...@debian.org) [140212 19:00]:
> 
> >> Packages should normally support the default Linux init system.  There
> 
> > I would drop the word "Linux" here - Packages should support our default
> > init systems.
> 
> That's a much stronger statement than we've made about support for the
> non-Linux ports in the past, where they're treated at most like another
> release architecture, which means that packages that have never worked on
> that architecture are not expected to do so and packages that used to work
> but stopped are sometimes removed from just that architecture rather than
> ported depending on the situation.

My expectation of packages is indeed that they work on as many
architectures as reasonable possible, and this includes that they
support the default init system there. (The question of "which
severity does a bug have" is a different question, for a release
architecture that bug would be serious according to
https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
and I don't think we should lower the bar.)

I don't think that this expectation is wrong.


> >> are some exceptional cases where lack of support for the default
> >> init system may be appropriate, such as alternative init system
> >> implementations, special-use packages such as managers for
> >> non-default init systems, and cooperating groups of packages
> >> intended for use with non-default init systems.  However, package
> >> maintainers should be aware that a requirement for a non-default
> >> init system will mean the package will be unusable for most Debian
> >> users and should normally be avoided.
> 
> > Also, I would think it appropriate if packages should (i.e. in case
> > appropriate patches are available) support other init systems, and not
> > depend on the default init systems.
> 
> I think that's already covered in the paragraph after this one.

If we agree on that, then we don't need to duplicate that.

> >> The Technical Committee offers no advice at this time on requirements
> >> or package dependencies on specific init systems after the jessie
> >> release.  There are too many variables at this point to know what the
> >> correct course of action will be.
> 
> > I think we could just drop the whole paragraph.
> 
> Why do you want to drop it?

Because I currently don't see why we should say that (or: whats in
there which is not already said elsewhere), and in that case, less
text is better.



Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140215103651.gi16...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Olav Vitters]

On Fri, Feb 14, 2014 at 03:31:41PM +0100, Josselin Mouette wrote:
> Le vendredi 14 février 2014 à 13:50 +, Ian Jackson a écrit : 
> > Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > > In all cases, it is unacceptable to put the burden of implementing
> > > logind on non-systemd systems on maintainers of packages that just need
> > > the logind interfaces. If it is not available, software such as gdm3
> > > will depend, directly or indirectly, on systemd as PID 1, and that will
> > > be all.
> > 
> > Firstly, I think the scenario where the required integration work is
> > not done is unlikely.  But in that scenario, we have two choices:
> >  (a) Effectively, drop all init systems other than systemd
> >  (b) Effectively, drop GNOME

>From my personal view, GNOME should not block any work to make GNOME
work properly on other init systems. I'd love something which implements
the various systemd APIs, but then on *BSD and so on.

GNOME developers have worked and work on various infrastructure projects
as well. Various of these are freedesktop.org projects. Hereby sometimes
causing confusion. E.g. ConsoleKit and UPower are/were not driven by
GNOME; these are freedesktop.org projects.

GNOME is totally open to anyone providing alternative implantations for
systemd APIs, though IMO we're not a party in that. I'd love if someone
would write something that works on *BSD. Note that there are a few
GNOME developers people who've installed FreeBSD for the first time ever
just to improve the *BSD experience (within the scope of GNOME).

In case there is a distribution policy that prevents GNOME from being
packaged then we'll work with the distribution to integrate the
distributions work. Provided that the patches are reasonable.

If distribution policy is more demanding than what the distribution can
cope with itself, then there is no problem making a reasonable request
in how we can assist. In case of init system development, I suggest
first asking init system developers for assistance. However, if all
fails then seems unfortunate if GNOME is dropped. I don't any sudden
change in the scope of GNOME (meaning: we are not init system developers
and we should limit ourselves to ensure APIs could have an alternative
implementation).

> You can have (c) GNOME depends on systemd.

And
(d) have other init systems do the maintenance for alternative
implementations. Have upstream and/or package maintainers be reasonable
in integrating that work.

> Same for KDE and Xfce, BTW, since they are going in the same direction.

Agreed, various things are freedesktop.org projects.

-- 
Regards,
Olav (all comments my own POV, not on behalf of GNOME)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140215134613.gd7...@bkor.dhs.org

Bug#727708: init system coupling etc.

[Russ Allbery]

Svante Signell  writes:

>> * Russ Allbery (r...@debian.org) [140212 19:00]:
>> > Packages should normally support the default Linux init system.  There
>> 
>> I would drop the word "Linux" here - Packages should support our
>> default init systems.

> If you do that then you have killed all non-linux architectures, is
> that intentional?

You have misunderstood Andi's point, I think.  What I believe he's trying
to say is that the level of support for the default Linux init system and
the default init system on kFreeBSD or Hurd should be the same, and talked
about the same.  In other words, if sysvinit is the default init system on
kFreeBSD, that should be supported at the same level and with the same
priority as systemd support on Linux.

> Debian is digging their own grave with respect to Free Software (not not
> FOSS or FOS), why don't you align with M$soft, Apple or especially
> RedHat :( Debian will just be a memory in a few years, RedHat will be
> the solution for everybody (TM).

Please take this sort of thing to some other mailing list.  It's not going
to change the mind of anyone here; it's just annoying and basically
content-free.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87bny8xiyq@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Svante Signell]

> On 2014-02-14 15:46:18 +, Ian Jackson wrote:
> > Ansgar Burchardt writes ("Bug#727708: init system coupling etc."):
> > > Don't you mean "drop GNOME, KDE and others"? It's not only GNOME that
> > > plans to depend on logind...
> > 
> > logind is a red herring because AIUI we already have a technical
> > solution to that.  The problem is other things that might be in the
> > pipeline.

It does not, see e.g. bug: 736880, or bug 602724, wrt gdm3 a really old one.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392493734.3779.100.camel@PackardBell-PC

Bug#727708: init system coupling etc

[Svante Signell]

> > Debian is digging their own grave with respect to Free Software (not
> > FOSS or FOS), why don't you align with M$soft, Apple or especially
> > RedHat :( Debian will just be a memory in a few years, RedHat will be
> > the solution for everybody (TM).
> 
> Please take this sort of thing to some other mailing list.  It's not going
> to change the mind of anyone here; it's just annoying and basically
> content-free

Never mind now, just please read this message in (about) three years
from now, and judge for yourself (am I a fortune teller, or not? :))


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392495175.3779.110.camel@PackardBell-PC

Bug#727708: init system coupling etc.

[Ian Jackson]

Ian Jackson writes ("Bug#727708: init system coupling etc."):
> Ian Jackson writes ("Bug#727708: init system coupling etc."):
> > In the spirit of my response to Noah Meyerhans:
> > 
> > In general, software may not require a specific init system to be
> > pid 1.  The exceptions to this are as follows:
> >   * alternative init system implementations
> >   * special-use packages such as managers for init systems
> >   * cooperating groups of packages intended for use with specific init
> > systems
> >provided that these are not themselves required by other software
> >whose main purpose is not the operation of a specific init system.
> > 
> >Degraded operation with some init systems is tolerable, so long as
> >the degradation is no worse than a tolerable bug.  So the lack of
> >a particular init system does not excuse a bug nor reduce its
> >severity; but conversely, nor is a bug more serious simply because
> >it is an incompatibility of some software with some init
> >system(s).
> > 
> > Is this a clearer line to draw ?
> 
> I'd appreciate feedback from other TC members on this wording.

No-one has said anything.  Indeed hardly anyone has said anything at
all.

I hereby formally propose the text above as an amendment to the
current resolution proposal.

Unless someone says that they prefer my old vague text to this new
one, I intend to accept that amendment before the Call for Votes.

I'm going to try to go through this thread and produce a draft Call
for Votes based on the proposals, amendments etc. which have been
emailed so far.

I intend to Call for Votes at 18:30 UTC tomorrow.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21252.48158.359117.895...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Bdale Garbee]

Ian Jackson  writes:

> I'm going to try to go through this thread and produce a draft Call
> for Votes based on the proposals, amendments etc. which have been
> emailed so far.

That would be good, since I at least have sort of lost track of what you
think the ballot options will be at this point.

Bdale


pgp0bqxnxuBAD.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> Uwe Storbeck  writes:
> > On Feb 12, Russ Allbery wrote:
> 
> >> Packages should normally support the default Linux init system.
> > [..]
> >> Package maintainers are strongly encouraged to merge any contributions
> >> for support of init systems other than the Linux default, and to add
> >> that support themselves if they're willing and capable of doing so.
> 
> > Assumed a package has (only) start scripts for sysvinit. This satisfies
> > "Packages should normally support the default Linux init system" (using
> > sysvinit compatibility mode).  Someone provides patches to add native
> > support for upstart and systemd, maybe to use advanced features like
> > socket activation.  Following the above proposal the package maintainer
> > is encouraged to apply the patch for upstart (as an init system "other
> > than the Linux default"), but not the patch for systemd.
> 
> > Wouldn't it be better to change that to something like "for support of
> > any init system"?
> 
> Yes, that's much better.  Thanks!

I think we should probably take that as you proposing and accepting an
amendment to your formal proposal.  I'm going to prepare the draft CFV
on that basis.

But it would really help to be more explicit.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21252.58112.763902.792...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Steve Langasek]

On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
> Ian Jackson  writes:

> > I'm going to try to go through this thread and produce a draft Call
> > for Votes based on the proposals, amendments etc. which have been
> > emailed so far.

> That would be good, since I at least have sort of lost track of what you
> think the ballot options will be at this point.

Likewise, I've lost the thread of what has actually been proposed.

So I don't think a 24 hour period between draft CfV and CfV is adequate
here.  There have been a lot of proposals discussed in this thread, and it's
not at all clear which are stillborn and which people think warrant carrying
forward. 

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developerhttp://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: Digital signature

Bug#727708: init system coupling etc.

[Ian Jackson]

Keith Packard writes ("Re: Bug#727708: init system coupling etc."):
> The discussions held within the context of the default init bug were
> fruitful, and without rancor, which makes me hopeful that the project
> membership can drive this issue to consensus in the near future through
> the usual policy editing process. As such I'd like to amend this
> proposed ballot with an additional option:
> 
>  * The TC chooses to not pass a resolution on this issue at the current time.

I have transposed this into my draft ballot options (work in
progress).  But I wonder if you would prefer to amend it.  As it is it
doesn't say _what_ the TC is declining to pass a resolution on.  If it
passed, that would have to be inferred from the defeated alternatives.

Perhaps you would like to change this to something like:

   The TC chooses to not pass a resolution at the current time
   about whether software may require specific init systems.

I don't formally propose this because I see no point on voting on both
your proposed wording and this edited one.  But if you like this
wording, or wish you change it, you may do so, as the proposer of your
version.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21252.62296.983339.94...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Russ Allbery]

Ian Jackson  writes:

> I think we should probably take that as you proposing and accepting an
> amendment to your formal proposal.  I'm going to prepare the draft CFV
> on that basis.

> But it would really help to be more explicit.

Right, I know, I wasn't expecting you to have to do that.  I need to
produce an edited draft.  I had company all weekend, social activity last
night, and work is on fire, so time and attention has been a bit short.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87wqgr0y7m@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Ian Jackson]

Andreas Barth writes ("Re: Bug#727708: init system coupling etc."):
> * Russ Allbery (r...@debian.org) [140212 19:00]:
> > Packages should normally support the default Linux init system.  There
> 
> I would drop the word "Linux" here - Packages should support our
> default init systems.

For the avoidance of doubt, I don't think this is a formal proposal
for an amendment to Russ's text.  So it won't appear on the ballot.
If you would like it on the ballot, please clarify this.

Thanks,
Ian.
(CC to the bug restored)


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21252.62526.323282.466...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Russ Allbery]

Andreas Barth  writes:
> * Russ Allbery (r...@debian.org) [140214 04:36]:

>> That's a much stronger statement than we've made about support for the
>> non-Linux ports in the past, where they're treated at most like another
>> release architecture, which means that packages that have never worked
>> on that architecture are not expected to do so and packages that used
>> to work but stopped are sometimes removed from just that architecture
>> rather than ported depending on the situation.

> My expectation of packages is indeed that they work on as many
> architectures as reasonable possible, and this includes that they
> support the default init system there. (The question of "which severity
> does a bug have" is a different question, for a release architecture
> that bug would be serious according to
> https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
> and I don't think we should lower the bar.)

> I don't think that this expectation is wrong.

That's a very good point.

How does this sound to you?

Packages should normally support the default init system on all
architectures for which they are built.  There are some exceptional
cases where lack of support for the default init system may be
appropriate, such as alternative init system implementations,
special-use packages such as managers for non-default init systems,
and cooperating groups of packages intended for use with non-default
init systems.  However, package maintainers should be aware that a
requirement for a non-default init system will mean the package will
be unusable for most Debian users and should normally be avoided.

> Because I currently don't see why we should say that (or: whats in there
> which is not already said elsewhere), and in that case, less text is
> better.

Given that the previous paragraph contains a lot of specific advice for
the jessie release, I feel like it adds some clarity to say explicitly
that we don't have advice to offer for the next release after jessie at
this time.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87k3cr0xlp@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Ian Jackson]

Steve Langasek writes ("Bug#727708: init system coupling etc."):
> On Wed, Feb 19, 2014 at 09:37:50AM -0700, Bdale Garbee wrote:
> > That would be good, since I at least have sort of lost track of what you
> > think the ballot options will be at this point.
> 
> Likewise, I've lost the thread of what has actually been proposed.
> 
> So I don't think a 24 hour period between draft CfV and CfV is adequate
> here.  There have been a lot of proposals discussed in this thread, and it's
> not at all clear which are stillborn and which people think warrant carrying
> forward. 

I think this is in fact perfectly clear.  But I am prepared to commit
to a further 24h extension if you promise that you will not ask for
even more time beyond that.

Note that there is no constitutional rule which prevents anyone from
proposing amendments right up to the CFV, and those amendments must
then appear on the CFV.  So ensuring a minimum period between draft
CFV and actual CFV is not possible without admitting a potentially
indefinite delay to the actual CFV.  Draft CFVs have no constitutional
status.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21252.63929.819557.123...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 13, 2014 at 06:51:13PM +, Ian Jackson wrote:
> In the spirit of my response to Noah Meyerhans:
> 
> In general, software may not require a specific init system to be
> pid 1.  The exceptions to this are as follows:
>   * alternative init system implementations
>   * special-use packages such as managers for init systems
>   * cooperating groups of packages intended for use with specific init
>   systems
>provided that these are not themselves required by other software
>whose main purpose is not the operation of a specific init system.
> 
>Degraded operation with some init systems is tolerable, so long as
>the degradation is no worse than a tolerable bug.  So the lack of
>a particular init system does not excuse a bug nor reduce its
>severity; but conversely, nor is a bug more serious simply because
>it is an incompatibility of some software with some init
>system(s).
> 
> Is this a clearer line to draw ?

This is largely clearer, thank you, but I find myself tripping over the
repetition of "tolerable" - it looks tautologous to me until about the
third reading - and the start of the second sentence is hard for me to
understand.  How about this amendment?

diff --git a/727708_initsystem/coupling-iwj-col-iwj.txt 
b/727708_initsystem/coupling-iwj-col-iwj.txt
index fc229ea..f14359c 100644
--- a/727708_initsystem/coupling-iwj-col-iwj.txt
+++ b/727708_initsystem/coupling-iwj-col-iwj.txt
@@ -24,11 +24,12 @@
whose main purpose is not the operation of a specific init system.
 
Degraded operation with some init systems is tolerable, so long as
-   the degradation is no worse than a tolerable bug.  So the lack of
-   a particular init system does not excuse a bug nor reduce its
-   severity; but conversely, nor is a bug more serious simply because
-   it is an incompatibility of some software with some init
-   system(s).
+   the degradation is no worse than what the Debian project would
+   consider a tolerable (non-RC) bug even if it were affecting all
+   users.  So the lack of support for a particular init system does not
+   excuse a bug nor reduce its severity; but conversely, nor is a bug
+   more serious simply because it is an incompatibility of some software
+   with some init system(s).
 
Maintainers are encouraged to accept technically sound patches
to enable improved interoperation with various init systems.

I don't want to get into overspecifying what's tolerable and what's not,
but this seems like a useful clarification and hopefully common ground.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220001052.ga14...@riva.ucam.org

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 13, 2014 at 07:55:25PM -0800, Russ Allbery wrote:
> Colin Watson  writes:
> > I'm currently undecided about whether I prefer the approach of setting
> > technical policy under 6.1.1 or offering advice under 6.1.5.  Bearing in
> > mind all the process discussions we've had, I can see that it might be
> > better to take the approach of offering technical advice rather than
> > getting (re-)embroiled in a distracting procedural dispute about whether
> > the Constitution entitles us to rule in advance on a subject that hasn't
> > clearly been asked of us by some other first-responding maintainer.
> 
> I also think Keith's point that the normal process for setting Policy can
> probably handle this is entirely correct.  Certainly, I don't think there
> will be substantial difficulties hammering out a Policy change given
> advice from the TC.  If there is, we can always deal with it at that
> point.

Having slept on it a few times, my conclusion on this point is that
which power we use won't affect my decision either way.  The policy team
would surely need to hammer out the exact letter of the policy in any
event (unless we're proposing that the TC's resolution should contain a
policy diff, which nobody seems to be seriously suggesting).

> > The first paragraph of the "loose coupling" section is replaced by
> > the following:
> 
> >   In general, software may not require a specific init system to be pid
> >   1, although degraded operation is tolerable.  The exceptions to this
> >   are as follows:
> 
> >* alternative init system implementations
> >* special-use packages such as managers for init systems
> >* cooperating groups of packages intended for use with specific init
> >  systems
> 
> >   provided that these are not themselves required by other software
> >   whose main purpose is not the operation of a specific init system.
> 
> >   Maintainers are encouraged to accept technically sound patches
> >   to enable improved interoperation with various init systems.
> 
> There's probably no chance that I will vote any version of L above FD, so
> feel free to disregard this.  But I think this is begging for some sort of
> definition of "specific."
> 
> As written, it seems like it either requires all packages in the archive
> add runit configuration, since otherwise they're not supporting all init
> systems available in Debian, or alternately that any package that provides
> a runit configuration and an OpenRC configuration and depends on runit |
> openrc is fine, since it doesn't depend on "a" specific init system (it
> depends on one of two specific init systems).
> 
> I don't think either of those are what you intend here.  But I'm at a loss
> as to what you *do* intend.  Explain it to me like I'm five?  :)

What I mean by this is that software (with all the exceptions above) may
not be shipped in a configuration where you can only use it with certain
init systems.  For service startup, that just means shipping sysvinit
scripts.  For other interfaces, that means restricting ourselves to the
subset of interfaces that people have figured out how to make work with
other init systems as pid 1.

runit is an interesting case which I admit I hadn't really looked at
before; I assume you aren't talking about its sysvinit compatibility
mode, but rather the mode where you use it as pid 1 (e.g.
init=/sbin/runit-init).  In this case, I would point out that its
documentation already says that you need to do the following when
replacing pid 1:

  Step 5: Service migration

  The goal is to migrate all services from sysvinit scheme to the runit
  service supervision design; take a look at these [run scripts] for
  popular services. The migration can be done smoothly. For those
  services that are not migrated to use run scripts yet, add the
  corresponding init-script startup to /etc/runit/1, e.g.:

   #!/bin/sh
   # one time tasks

   /etc/init.d/kerneld start
   /etc/init.d/rmnologin

   touch /etc/runit/stopit
   chmod 0 /etc/runit/stopit

  It is possible to just add /etc/init.d/rc 2 for having all services
  from the former runlevel 2 started as one time tasks, but keep the
  goal above in mind, supervising services has great advantages.

[etc.]

So I would argue that if this is the expectation set by the init
system's own documentation, then no higher bar should be set.

Similarly, if somebody uploads a new init system to Debian which has no
sysvinit compatibility and thus does basically nothing useful to start
with, then that system is de facto RC buggy in that it can't boot a
useful Debian system, and it shouldn't be other packages' responsibility
to deal with the fact that that init system has no reasonable migration
path.

I will concede that my amendment is not terribly explicit about this.
I'm not sure how to make it more explicit without cut-and-pasting the
above into it, which I think would be a bit much.  Russ, I know you said
you weren't likely to vote for this, but I don't suppo

Bug#727708: init system coupling etc.

[Ian Jackson]

Colin Watson writes ("Bug#727708: init system coupling etc."):
> On Thu, Feb 13, 2014 at 06:51:13PM +, Ian Jackson wrote:
> > Is this a clearer line to draw ?
> 
> This is largely clearer, thank you, but I find myself tripping over the
> repetition of "tolerable" - it looks tautologous to me until about the
> third reading - and the start of the second sentence is hard for me to
> understand.  How about this amendment?

Thanks for looking at this.

> diff --git a/727708_initsystem/coupling-iwj-col-iwj.txt 
> b/727708_initsystem/coupling-iwj-col-iwj.txt
...
> Degraded operation with some init systems is tolerable, so long as
> -   the degradation is no worse than a tolerable bug.  So the lack of
> -   a particular init system does not excuse a bug nor reduce its
> -   severity; but conversely, nor is a bug more serious simply because
> -   it is an incompatibility of some software with some init
> -   system(s).
> +   the degradation is no worse than what the Debian project would
> +   consider a tolerable (non-RC) bug even if it were affecting all
> +   users.  So the lack of support for a particular init system does not
> +   excuse a bug nor reduce its severity; but conversely, nor is a bug
> +   more serious simply because it is an incompatibility of some software
> +   with some init system(s).

I think this is a useful clarification and I accept this amendment.

Colin, since you already have it to hand in git I see, could you
commit it directly there to the same file ?

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21253.23254.363431.904...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 20, 2014 at 01:31:02AM +, Ian Jackson wrote:
> I think this is a useful clarification and I accept this amendment.
> 
> Colin, since you already have it to hand in git I see, could you
> commit it directly there to the same file ?

Sure, thanks - done.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220024750.gk6...@riva.ucam.org

Bug#727708: init system coupling etc.

[Russ Allbery]

Colin Watson  writes:

> What I mean by this is that software (with all the exceptions above) may
> not be shipped in a configuration where you can only use it with certain
> init systems.  For service startup, that just means shipping sysvinit
> scripts.  For other interfaces, that means restricting ourselves to the
> subset of interfaces that people have figured out how to make work with
> other init systems as pid 1.

If you do mean that all packages with init system configuration have to
ship sysvinit scripts, I wish the wording would actually say that.  This
potentially matters in the long run.  For example, consider a hypothetical
future world in which systemd, upstart, and OpenRC are packaged for Debian
and sysvinit has gone away.  In that world, I would maintain separate
configuration for systemd, upstart, and OpenRC, since I consider
maintaining those three separate files to be easier than maintaining a
sysvinit script.  Is that permitted?  If it is permitted, does my package
become instantly buggy when someone packages openlaunchd for Debian?

The second is also ambiguous, albeit less so.  "Figured out how to make
work with other init systems" != "figured out how to make work with all
init systems."  It's possible to imagine services that work with upstart
and systemd but don't work with sysvinit, although I don't know of any
currently.

> runit is an interesting case which I admit I hadn't really looked at
> before; I assume you aren't talking about its sysvinit compatibility
> mode, but rather the mode where you use it as pid 1 (e.g.
> init=/sbin/runit-init).  In this case, I would point out that its
> documentation already says that you need to do the following when
> replacing pid 1:

Oh, sure, it's an artificial example, and I would be surprised if anyone
ran Debian in this model.  But my point is that L is (unlike T) apparently
intended to be normative text as opposed to advice, but the normative text
is not sufficiently clear so that package maintainers know what they're
supposed to do, or (switching hats for a moment) Policy editors know what
they're supposed to be documenting.

> Similarly, if somebody uploads a new init system to Debian which has no
> sysvinit compatibility and thus does basically nothing useful to start
> with, then that system is de facto RC buggy in that it can't boot a
> useful Debian system, and it shouldn't be other packages' responsibility
> to deal with the fact that that init system has no reasonable migration
> path.

> I will concede that my amendment is not terribly explicit about this.
> I'm not sure how to make it more explicit without cut-and-pasting the
> above into it, which I think would be a bit much.  Russ, I know you said
> you weren't likely to vote for this, but I don't suppose you could
> suggest some language which at least makes the meaning reasonably
> watertight to you per the above?

I think what you're trying to say, from the above, is:

All software that needs init system configuration must include
sysvinit scripts.  Software may not require any functionality from the
init system that cannot be provided via init scripts, although
degraded operation is tolerable.  The exceptions to this are as
follows:

Also, I assume that this language intends to say that this is forever.  In
other words, no package is ever permitted to drop sysvinit scripts,
regardless of what init systems are in use in Debian, at least until the
TC issues another ruling.

If L passed, that's what I'd assume I was supposed to put in Policy.  If
that's *not* what you mean, well, I think it's even more important to
clarify this somehow.

>> >> For the jessie release, all packages that currently support being run
>> >> under sysvinit should continue to support sysvinit unless there is no
>> >> technically feasible way to do so.
>> 
>> "packages" here should probably actually be "software" for all the reasons
>> discussed elsewhere.

> I agree.  Russ, how about this amendment?

> diff --git a/727708_initsystem/coupling-russ.txt 
> b/727708_initsystem/coupling-russ.txt
> index 242505a..dfc1ded 100644
> --- a/727708_initsystem/coupling-russ.txt
> +++ b/727708_initsystem/coupling-russ.txt
> @@ -2,32 +2,30 @@
>  Technical Committee under section 6.1.5 of the constitution.  It does
>  not constitute an override of maintainer decisions past or future:
>  
> -Packages should normally support the default Linux init system.  There
> +Software should normally support the default Linux init system.  There
>  are some exceptional cases where lack of support for the default init
>  system may be appropriate, such as alternative init system
>  implementations, special-use packages such as managers for non-default
>  init systems, and cooperating groups of packages intended for use with
> -non-default init systems.  However, package maintainers should be
> -aware that a requirement for a non-default init system will mea

Bug#727708: init system coupling etc.

[Ian Jackson]

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> If you do mean that all packages with init system configuration have to
> ship sysvinit scripts, I wish the wording would actually say that.  This
> potentially matters in the long run.  For example, consider a hypothetical
> future world in which systemd, upstart, and OpenRC are packaged for Debian
> and sysvinit has gone away.  In that world, I would maintain separate
> configuration for systemd, upstart, and OpenRC, since I consider
> maintaining those three separate files to be easier than maintaining a
> sysvinit script.  Is that permitted?  If it is permitted, does my package
> become instantly buggy when someone packages openlaunchd for Debian?

The draft text in my option says:

   In general, software may not require a specific init system to be
^^
   pid 1.  The exceptions to this are as follows:

I think this leaves open the possibility that software might not work
with certain init systems.  I'm not trying to say that all software
must work properly with all init systems, no matter how experimental
or broken.  (Although that would be nice of course.)

In particular, I don't think this is imposing a requirement for
daemons to work with init systems which do not provide at least a
compatibility mode for common interfaces (at the moment, the common
interfaces for this include sysvinit scripts, inetd.conf and perhaps
something else I haven't thought of).

In practice what I would like to see is a kind of more powerful
compability mechanism that is better able to exploit the better
behaviours of more modern daemon supervisors.

But at the moment the main compatibility mechanism sysvinit scripts,
and all of our init systems support sysvinit scripts.  So that means
that all packages should ship sysvinit scripts.  Work is ongoing on
other kinds of compatibility approaches.  (It's not even necessary for
all daemon packages or all init systems to use the same compatibility
approach.)

I'm relaxed about the idea of packages having to ship sysvinit scripts
indefinitely.  Shipping sysvinit scripts does not mean that they have
to be handwritten.  It would be perfectly feasible for a daemon which
only supported a sensible non-forking startup approach to provide an
init script which is autogenerated from some kind of meta information
(and to use a helper tool for daemonisation).

I think there's a clear segment of opinion in the project and amongst
our users who want to keep the traditional sysvinit approach.  It's
not clear whether a minority or a majority will actually want to run
sysvinit indefinitely, but even if we think other approaches are
better that doesn't mean we should be forcing them on everyone.

> I think what you're trying to say, from the above, is:
> 
> All software that needs init system configuration must include
> sysvinit scripts.  Software may not require any functionality from the
> init system that cannot be provided via init scripts, although
> degraded operation is tolerable.  The exceptions to this are as
> follows:
> 
> Also, I assume that this language intends to say that this is forever.  In
> other words, no package is ever permitted to drop sysvinit scripts,
> regardless of what init systems are in use in Debian, at least until the
> TC issues another ruling.
> 
> If L passed, that's what I'd assume I was supposed to put in Policy.  If
> that's *not* what you mean, well, I think it's even more important to
> clarify this somehow.

For now, yes, you should put that into policy.  If we later come up
with a better compatibility approach, policy can be amended.  The TC
decision is defining the objectives, not the details.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21254.1984.23537.903...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Thorsten Glaser]

Ian Jackson dixit:

>(and to use a helper tool for daemonisation).

mksh -T- -c 'exec daemond arg1 …'

bye,
//mirabilos
-- 
„Cool, /usr/share/doc/mksh/examples/uhr.gz ist ja ein Grund,
mksh auf jedem System zu installieren.“
-- XTaran auf der OpenRheinRuhr, ganz begeistert
(EN: “[…]uhr.gz is a reason to install mksh on every system.”)


--
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/pine.bsm.4.64l.1402201356270.29...@herc.mirbsd.org

Bug#727708: init system coupling etc.

[Ian Jackson]

I'm writing here in a purely secretarial capacity.

Russ Allbery writes ("Bug#727708: init system coupling etc."):
> Colin Watson  writes:
> > I agree.  Russ, how about this amendment?

Is that a formal proposal ?

> > diff --git a/727708_initsystem/coupling-russ.txt 
> > b/727708_initsystem/coupling-russ.txt
> > index 242505a..dfc1ded 100644
[etc]
> 
> This seems fine.

And is this an acceptance ?


As a matter of process, it would be very wise for everyone to at least
make all statements approving changes to these kind of resolutions as
formal proposals.  That way you don't risk not having time to
explicitly accept the formal amendment before the CFV.

Likewise if a TC member thinks a change is important enough that they
want to press for it, it would be better to propose it as a formal
amendment.  It can always be withdrawn or accepted later.  A TC member
would be well-advised to make such a formal proposal iff they want
something like their suggestion to be on the ballot.


I think in the absence of clarity, when preparing the CFV, I should
probably proceed on the following basis:

  - Statements from TC members suggesting changes but not explicitly
stating that they are formal proposals, are not formal proposals.

Rationale: This avoids the ballot being clogged up with a
profusion of suggested edits which the suggester probably didn't
want to put onto the ballot if not accepted.

  - Statements from TC members expressing unqualified approval of
suggested edits to their own texts are to be treated as formal
acceptance of amendments (including formal proposal of the
amendment if necessary).  Even if the TC member's message does
not contain an explicit "I hereby ..." statement.

Rationale: This avoids the ballot containing older versions of a
text in a situation where a TC member didn't get around to
whatever tidying up or redrafting they felt they were waiting for.

If anyone disagrees with this, please say.


So accordingly, I intend to treat Russ's "this seems fine" as an
acceptance of Colin's suggestion.

> > -For the jessie release, all packages that currently support being run
> > +For the jessie release, all software that currently supports being run
> >  under sysvinit should continue to support sysvinit unless there is no
> >  technically feasible way to do so.  Reasonable changes to preserve or
> >  improve sysvinit support should be accepted through the jessie
> >  release.  There may be some loss of functionality under sysvinit if
> 
> This looks good.

And this.

But not the other suggestions in Colin's mail, which Russ either
didn't quote or disagreed with.


But for now I'm not going to make these changes in git.  Instead I'm
going to drop the message-id of Russ's message into the git repo as a
note that it contains accepted amendments which need integrating.

That will save effort if Russ decides to rewrite or re-edit the file
himself.

I trust this meets with everyone's approval.  Sorry to be so
long-winded and pernickety about process, but I don't want to make
sure that we all agree on the process and the proprieties and I don't
want anyone to be taken by surprise.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21254.3306.143424.366...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Ian Jackson writes ("Bug#727708: init system coupling etc."):
> Steve Langasek writes ("Bug#727708: init system coupling etc."):
> > So I don't think a 24 hour period between draft CfV and CfV is
> > adequate here.  There have been a lot of proposals discussed in
> > this thread, and it's not at all clear which are stillborn and
> > which people think warrant carrying forward.
> 
> I think this is in fact perfectly clear.  But I am prepared to commit
> to a further 24h extension if you promise that you will not ask for
> even more time beyond that.

I've not heard from Steve.  Under the circumstances I think it would
be entirely reasonable of me to call for votes at 18:30 UTC today as I
originally said I would.  However, I don't want to get into another
process row.

Also Russ and Colin do seem still to be working on final improvements
to Russ's text.  So, I'm going to wait another day.

I will Call for Votes at 18:00 UTC tomorrow, Friday.  I'm going to
send another Draft CFV this evening at around the same time, including
whatever amendments etc. have been put forward by then.

In the meantime I'm generally transferring formal actions into the git
repo so that I don't have to go through my mailbox again later looking
for them.

As I have previously said, there is nothing stopping anyone putting
forward amendments right up to the Call for Votes.  But I don't want
to delay this CFV again.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21254.3709.219508.2...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Colin Watson]

On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
> Colin Watson  writes:
> > What I mean by this is that software (with all the exceptions above) may
> > not be shipped in a configuration where you can only use it with certain
> > init systems.  For service startup, that just means shipping sysvinit
> > scripts.  For other interfaces, that means restricting ourselves to the
> > subset of interfaces that people have figured out how to make work with
> > other init systems as pid 1.
> 
> If you do mean that all packages with init system configuration have to
> ship sysvinit scripts, I wish the wording would actually say that.  This
> potentially matters in the long run.  For example, consider a hypothetical
> future world in which systemd, upstart, and OpenRC are packaged for Debian
> and sysvinit has gone away.  In that world, I would maintain separate
> configuration for systemd, upstart, and OpenRC, since I consider
> maintaining those three separate files to be easier than maintaining a
> sysvinit script.  Is that permitted?  If it is permitted, does my package
> become instantly buggy when someone packages openlaunchd for Debian?

I've gone back and forth in my own mind about how/whether we ought to be
sunsetting this stuff, so apologies if this contradicts something I've
previously said.  My preference is (to borrow a phrase from British
constitutional law) that the TC should not be trying to bind its
successor.  I'm entirely happy for us to set policy (or give advice,
whatever) based on how things stand at the moment, and revisit it later
when the landscape changes.

I know we're all tired of this debate at the moment.  But if and when
sysvinit goes away, I think it'll be relatively straightforward by
comparison to establish revised policy in light of that, and it will be
much clearer then what that policy ought to say than it is now.  There
doesn't seem any danger that we'll forget about this.

My instinct is that in the new world you outline where we
(hypothetically) have no common subset of service configuration among
init systems, we probably ought to end up with an explicitly supported
list of init systems (determined at a more lightweight level than the
TC) and any new init system would have the job of fleshing out enough
support in the archive to convince us to add it to that list.  But I
explicitly don't want to try to lay out something like that now; we
don't need it yet and it would be unnecessarily contentious.

Would it improve things if we added an informative paragraph such as
this?  (I'm not necessarily asking whether it would lead you to rank
this option higher, just whether it makes the intent clearer.)

  This policy is intended for the current situation where most services
  can still easily include support for multiple init systems by means
  such as shipping a sysvinit script.  If this changes then we expect to
  revise this policy or ask the policy editors to do so.

> The second is also ambiguous, albeit less so.  "Figured out how to make
> work with other init systems" != "figured out how to make work with all
> init systems."  It's possible to imagine services that work with upstart
> and systemd but don't work with sysvinit, although I don't know of any
> currently.

This is a situation that some people have raised but that I honestly
don't consider interesting.  Upstart and systemd are different enough,
and Upstart takes a minimal enough approach to the interfaces it offers,
that a service that (non-trivially, i.e. not just with straightforward
job/unit files) supports both has IMO demonstrated enough extensibility
that it wouldn't be hard to port to other things.  Consider the single
cgroup writer in cgmanager as an example: that's a separate add-on
service that has nothing Upstart-specific about it and should work just
as well with other init systems.

I understand that there is a theoretical ambiguity here, but I'm not
sure how to tighten it up and I'm not keen on spending time doing so
since I think it will remain theoretical.

> > Similarly, if somebody uploads a new init system to Debian which has no
> > sysvinit compatibility and thus does basically nothing useful to start
> > with, then that system is de facto RC buggy in that it can't boot a
> > useful Debian system, and it shouldn't be other packages' responsibility
> > to deal with the fact that that init system has no reasonable migration
> > path.
> 
> > I will concede that my amendment is not terribly explicit about this.
> > I'm not sure how to make it more explicit without cut-and-pasting the
> > above into it, which I think would be a bit much.  Russ, I know you said
> > you weren't likely to vote for this, but I don't suppose you could
> > suggest some language which at least makes the meaning reasonably
> > watertight to you per the above?
> 
> I think what you're trying to say, from the above, is:
> 
> All software that needs init system configuration must include
> sysvinit scripts. 

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 20, 2014 at 02:31:06PM +, Colin Watson wrote:
> On Wed, Feb 19, 2014 at 06:55:31PM -0800, Russ Allbery wrote:
> > If you do mean that all packages with init system configuration have to
> > ship sysvinit scripts, I wish the wording would actually say that.  This
> > potentially matters in the long run.  For example, consider a hypothetical
> > future world in which systemd, upstart, and OpenRC are packaged for Debian
> > and sysvinit has gone away.  In that world, I would maintain separate
> > configuration for systemd, upstart, and OpenRC, since I consider
> > maintaining those three separate files to be easier than maintaining a
> > sysvinit script.  Is that permitted?  If it is permitted, does my package
> > become instantly buggy when someone packages openlaunchd for Debian?
> 
> I've gone back and forth in my own mind about how/whether we ought to be
> sunsetting this stuff, so apologies if this contradicts something I've
> previously said.  My preference is (to borrow a phrase from British
> constitutional law) that the TC should not be trying to bind its
> successor.  I'm entirely happy for us to set policy (or give advice,
> whatever) based on how things stand at the moment, and revisit it later
> when the landscape changes.
> 
> I know we're all tired of this debate at the moment.  But if and when
> sysvinit goes away, I think it'll be relatively straightforward by
> comparison to establish revised policy in light of that, and it will be
> much clearer then what that policy ought to say than it is now.  There
> doesn't seem any danger that we'll forget about this.

Also, after rereading your proposal, I notice you have a post-jessie
sunset clause where we would have to renew our advice if we wanted it to
continue to be effective (is this very meaningful in an informative
context?).  While I agree with your too-many-variables sentence, I
prefer this indefinite until-we-decide-otherwise approach, because
engineering timescales are wildly variable even in the corporate world
never mind in a volunteer project.  We definitely want our
advice/policy/whatever to be effective up to the release of jessie for
practical upgrade reasons, but I would prefer that changes after that be
in response to definite changes in the init system landscape, rather
than simply the passage of time and Debian releases.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140220144318.ga30...@riva.ucam.org

Bug#727708: init system coupling etc.

[Ian Jackson]

Colin Watson writes ("Bug#727708: init system coupling etc."):
> Would it improve things if we added an informative paragraph such as
> this?  (I'm not necessarily asking whether it would lead you to rank
> this option higher, just whether it makes the intent clearer.)
> 
>   This policy is intended for the current situation where most services
>   can still easily include support for multiple init systems by means
>   such as shipping a sysvinit script.  If this changes then we expect to
>   revise this policy or ask the policy editors to do so.

I guess open to the idea of a clarification along these lines, but I
would want to ensure that this was limited to the question of service
startup.  Otherwise we will be faced with claims that the new foobard
service provided by only one init system is now absolutely mandatory
for subsystem wombat and this paragraph justifies revisiting the
situation.

Frankly I find it difficult to imagine a situation where it is
impractical, or even an unacceptable amount of work, to provide
service startup for multiple init systems.

> I understand that there is a theoretical ambiguity here, but I'm not
> sure how to tighten it up and I'm not keen on spending time doing so
> since I think it will remain theoretical.

Quite.

> > I think what you're trying to say, from the above, is:
> > 
> > All software that needs init system configuration must include
> > sysvinit scripts.  Software may not require any functionality from the
> > init system that cannot be provided via init scripts, although
> > degraded operation is tolerable.  The exceptions to this are as
> > follows:
> 
> I would be fine with this, perhaps with s/require/have a hard
> requirement of/ for the sake of emphasis, and s/via init scripts/via
> init scripts or other similar compatibility mechanisms/.  But it's
> really Ian's proposal; Ian, what do you think?

I think it's better not to get into implementation details.

If someone comes up with a compatibility approach that doesn't involve
packages actually shipping sysvinit scripts, we wouldn't want to rule
it out.  Eg, perhaps the sysvinit scripts are autogenerated at
package install time; or perhaps the package is started by a
supervisor daemon which itself has a sysvinit script, but the package
itself only has configuration for said supervisor (and perhaps no
other init system config at all).

I have some opinions about the best approaches to cross-init-system
compatibility but I wouldn't want the TC to prevent policy from
evolving if experience shows those opinion to be wrong, or even if
simply the people doing the work decide to do things differently.

So I agree that _at the moment_ the TC wording implies that everyone
must ship a sysvinit script.  But with future advances or changes
that may cease to be true.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21254.5399.955219.825...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson  writes:

> Perhaps you would like to change this to something like:
>
>The TC chooses to not pass a resolution at the current time
>about whether software may require specific init systems.
>
> I don't formally propose this because I see no point on voting on both
> your proposed wording and this edited one.  But if you like this
> wording, or wish you change it, you may do so, as the proposer of your
> version.

Thanks, yes, this looks better than my original version. Would you like
me to commit the change, or would you like to?

-- 
keith.pack...@intel.com


pgp1qf56IjNHl.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Russ Allbery]

Colin Watson  writes:

> Also, after rereading your proposal, I notice you have a post-jessie
> sunset clause where we would have to renew our advice if we wanted it to
> continue to be effective (is this very meaningful in an informative
> context?).

This was just an error on my part.  That was only supposed to apply to the
advice about sysvinit support, not to the entirety of the advice.  I think
the rest of it is generally applicable and doesn't need a sunset clause.

> While I agree with your too-many-variables sentence, I prefer this
> indefinite until-we-decide-otherwise approach, because engineering
> timescales are wildly variable even in the corporate world never mind in
> a volunteer project.  We definitely want our advice/policy/whatever to
> be effective up to the release of jessie for practical upgrade reasons,
> but I would prefer that changes after that be in response to definite
> changes in the init system landscape, rather than simply the passage of
> time and Debian releases.

I'm very reluctant to support a statement that *requires* that we have
this debate in the TC again.  I would prefer to let the project try to
work this out and only get involved again if we actually have to.

I don't want to get caught in the trap where we're assuming, even
implicitly, that the project will do something stupid unless the TC is
constantly keeping our hands on the wheel.  Maintainers really don't need
us to tell them how to do their work for the vast majority of issues and
decisions, and I fully expect that will apply to init systems as well once
we get through this rocky and controversial part.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87ppmh9hwf@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Ian Jackson]

Keith Packard writes ("Re: Bug#727708: init system coupling etc."):
> Ian Jackson  writes:
> > Perhaps you would like to change this to something like:
> >
> >The TC chooses to not pass a resolution at the current time
> >about whether software may require specific init systems.
...
> Thanks, yes, this looks better than my original version. Would you like
> me to commit the change, or would you like to?

I've done so, thanks.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.15111.624281.109...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Tollef Fog Heen]

]] Colin Watson 

> So, in my amendment, I intended this to be the "cooperating groups of
> packages intended for use with specific init systems", which language I
> think I borrowed from your proposal.  If logind-208 Depends: systemd (or
> indeed if it's part of systemd), then that's fine, as long as it doesn't
> end up being required by something else that isn't so intimately related
> to the init system; in other words, a dependency on systemd doesn't
> become any less a dependency on systemd just because it happens to be
> spelled "Depends: logind" and there's only one provider available.

To be honest, I'm not sure why init systems are being singled out
here. It's not really feasible to run both kdm and gdm at the same time,
or run multiple window managers at the same time or a whole host of
other software.  Or would you be as strongly opposed to having a tool
(say an accessibility tool) depend on GDM because it provided interfaces
that KDM doesn't?  (I'm not sure this is actually true, but I could
easily see it being true.)

I also find it curious how A depending on interface B provided by
packages C and D becomes RC buggy because D is unmaintained and gets
removed from the archive.  It's not how we usually treat bugs.

-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/m2txbu4dq1@rahvafeir.err.no

Bug#727708: init system coupling etc.

[Andreas Barth]

* Russ Allbery (r...@debian.org) [140219 19:24]:
> Andreas Barth  writes:
> > * Russ Allbery (r...@debian.org) [140214 04:36]:
> 
> >> That's a much stronger statement than we've made about support for the
> >> non-Linux ports in the past, where they're treated at most like another
> >> release architecture, which means that packages that have never worked
> >> on that architecture are not expected to do so and packages that used
> >> to work but stopped are sometimes removed from just that architecture
> >> rather than ported depending on the situation.
> 
> > My expectation of packages is indeed that they work on as many
> > architectures as reasonable possible, and this includes that they
> > support the default init system there. (The question of "which severity
> > does a bug have" is a different question, for a release architecture
> > that bug would be serious according to
> > https://release.debian.org/jessie/rc_policy.txt section 4 paragraph 4
> > and I don't think we should lower the bar.)
> 
> > I don't think that this expectation is wrong.
> 
> That's a very good point.
> 
> How does this sound to you?
> 
> Packages should normally support the default init system on all
> architectures for which they are built.  There are some exceptional
> cases where lack of support for the default init system may be
> appropriate, such as alternative init system implementations,
> special-use packages such as managers for non-default init systems,
> and cooperating groups of packages intended for use with non-default
> init systems.  However, package maintainers should be aware that a
> requirement for a non-default init system will mean the package will
> be unusable for most Debian users and should normally be avoided.

Better but I think we should also point out that supporting different
architectures is a good thing.

So the first sentence rather as
| Packages should support as many architectures as reasonably possible,
| and they should normally ...

Also I'd like to amend the last sentence with ", and could constitute
an serious bug of the package." (which is a correct observation
according to the current RC policy)




> > Because I currently don't see why we should say that (or: whats in there
> > which is not already said elsewhere), and in that case, less text is
> > better.
> 
> Given that the previous paragraph contains a lot of specific advice for
> the jessie release, I feel like it adds some clarity to say explicitly
> that we don't have advice to offer for the next release after jessie at
> this time.

Well, the paragraph cited above does apply not only to jessie (but
it's meaning could change depending on which architectures debian
supports in which way).

So I propose to change the text:
>
> The Technical Committee offers no advice at this time on requirements
> or package dependencies on specific init systems after the jessie
> release.  There are too many variables at this point to know what the
> correct course of action will be.

to
| The Technical Committee offers no advice regarding sysvinit
| compatibility at this time after the jessie release.  There are too
| many variables at this point to know what the correct course of action
| will be.

(the empty line above is there by purpose, i.e. it also merges this
paragraph with the previous one)



To avoid any doubt, this is a formal proposal for an amendment to
Russ's text, i.e. I would like to see it on the ballot.

I'll try to check my mail before 18:00 UTC but I cannot promise.


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221121535.gv12...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Ian Jackson]

Andreas Barth writes ("Bug#727708: init system coupling etc."):
> So I propose to change the text:
> >
> > The Technical Committee offers no advice at this time on requirements
> > or package dependencies on specific init systems after the jessie
> > release.  There are too many variables at this point to know what the
> > correct course of action will be.
> 
> to
> | The Technical Committee offers no advice regarding sysvinit
> | compatibility at this time after the jessie release.  There are too
> | many variables at this point to know what the correct course of action
> | will be.
> 
> (the empty line above is there by purpose, i.e. it also merges this
> paragraph with the previous one)

I will transpose this into git.

As an observation from a native English speaker, the language is
rather odd.  It is not conventional to have two time clauses next to
each other like that.  I would suggest (but do not formally propose):

   The Technical Committee offers no advice at this time regarding
   sysvinit compatibility after the jessie release.  There are too
   many variables at this point to know what the correct course of
   action will be.

Ie, move "at this time" to after "advice".

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/21255.18072.3672.313...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Andreas Barth writes ("Bug#727708: init system coupling etc."):
> Russ Allbery (r...@debian.org) [140219 19:24]:
> > How does this sound to you?
> > 
> > Packages should normally support the default init system on all
> > architectures for which they are built.  There are some exceptional
> > cases where lack of support for the default init system may be
> > appropriate, such as alternative init system implementations,
> > special-use packages such as managers for non-default init systems,
> > and cooperating groups of packages intended for use with non-default
> > init systems.  However, package maintainers should be aware that a
> > requirement for a non-default init system will mean the package will
> > be unusable for most Debian users and should normally be avoided.
> 
> Better but I think we should also point out that supporting different
> architectures is a good thing.
> 
> So the first sentence rather as
> | Packages should support as many architectures as reasonably possible,
> | and they should normally ...
> 
> Also I'd like to amend the last sentence with ", and could constitute
> an serious bug of the package." (which is a correct observation
> according to the current RC policy)

Russ has already amended his text to say "Software should ...".  So
when transposing your amendment onto Russ's new text, I have to decide
between using your new text verbatim (effectively reverting that
change), or treating your proposal as a request to change only the
parts you are actually aiming at.

I'm going to do the latter because it appears to best reflect your
intent.  This results in

Software should support as many architectures as reasonably possible,
and it should normally support the default [...]

(changing "they" to "it" to agree gramatically with "software" rather
than "packages").


> To avoid any doubt, this is a formal proposal for an amendment to
> Russ's text, i.e. I would like to see it on the ballot.

Thanks for being clear.

Regards,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.18558.715807.637...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

Andreas Barth writes ("Bug#727708: init system coupling etc."):
> Russ Allbery (r...@debian.org) [140219 19:24]:
> So I propose to change the text:
> >
> > The Technical Committee offers no advice at this time on requirements
> > or package dependencies on specific init systems after the jessie
> > release.  There are too many variables at this point to know what the
> > correct course of action will be.
> 
> to
> | The Technical Committee offers no advice regarding sysvinit
> | compatibility at this time after the jessie release.  There are too
> | many variables at this point to know what the correct course of action
> | will be.
> 
> (the empty line above is there by purpose, i.e. it also merges this
> paragraph with the previous one)

Looking at Russ's draft, he has already made an effectively identical
change.  Russ's wording is:

The Technical Committee offers no advice at this time on sysvinit
support beyond the jessie release.  There are too many variables at
this point to know what the correct course of action will be.

This differs from yours in the placement of "at this time" (see my
previous mail) and in that it uses "beyond the jessie release" rather
than "after the jessie release".  These don't seem to change the
meaning much for me but improve the way it reads.

You may wish to adopt Russ's wording.

Thanks,
Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.18777.874083.373...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Colin Watson]

On Thu, Feb 20, 2014 at 05:20:22AM +0100, Tollef Fog Heen wrote:
> ]] Colin Watson 
> > So, in my amendment, I intended this to be the "cooperating groups of
> > packages intended for use with specific init systems", which language I
> > think I borrowed from your proposal.  If logind-208 Depends: systemd (or
> > indeed if it's part of systemd), then that's fine, as long as it doesn't
> > end up being required by something else that isn't so intimately related
> > to the init system; in other words, a dependency on systemd doesn't
> > become any less a dependency on systemd just because it happens to be
> > spelled "Depends: logind" and there's only one provider available.
> 
> To be honest, I'm not sure why init systems are being singled out
> here. It's not really feasible to run both kdm and gdm at the same time,
> or run multiple window managers at the same time or a whole host of
> other software.  Or would you be as strongly opposed to having a tool
> (say an accessibility tool) depend on GDM because it provided interfaces
> that KDM doesn't?  (I'm not sure this is actually true, but I could
> easily see it being true.)

They're being singled out because this is actually something people have
been proposing to do, and other people have objected.

Regarding the hypothetical about display managers, I can *conceive* of
situations where this might be an issue.  It's less clear than with init
systems, though, because desktop software tends to naturally go with a
display manager in ways that it doesn't so naturally go with a
particular init system: assuming that grandomaccessibilitytool has a
visible interface, it's probably themed the same way as GDM, most of its
users will probably be using GDM already (or maybe LightDM, I suppose),
and so on.  It's technically possible but pretty unlikely that a KDE
tool will suddenly decide that it really needs GDM and thus conflict
with the rest of your KDE desktop, or in general that you'd end up
wanting to install multiple packages that require different display
managers, just because most people tend to stick within a cooperating
set of packages for their desktop environment.

> I also find it curious how A depending on interface B provided by
> packages C and D becomes RC buggy because D is unmaintained and gets
> removed from the archive.  It's not how we usually treat bugs.

I don't view this ballot option as stating that a particular package
becomes RC-buggy.  It's making a statement about how our software ought
to be structured, not specifically assigning problems to one end or
other of a dependency arc.  I still hold out some hope that maintainers
will actually cooperate and talk to each other about this kind of
problem ...

If part of an init system (whether packaged monolithically or as an
add-on) that's essential for the operation of other software in the
archive with that init system used to work but then ceases to be
maintained enough to be shippable, then that's a serious regression for
that init system and we would want to look at whether it's still viable
at all or perhaps whether the component in question can be resurrected.
It shouldn't be just a mindlessly static approach where package A
becomes RC-buggy and we don't think about the underlying reasons that
led up to it.  I think that situation is quite different, though, from
the situation where package A introduces a new interface dependency in a
way that's known to have only limited support.

-- 
Colin Watson   [cjwat...@debian.org]


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221134111.ga22...@riva.ucam.org

Bug#727708: init system coupling etc.

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:29]:
> Andreas Barth writes ("Bug#727708: init system coupling etc."):
> > So I propose to change the text:
> > >
> > > The Technical Committee offers no advice at this time on requirements
> > > or package dependencies on specific init systems after the jessie
> > > release.  There are too many variables at this point to know what the
> > > correct course of action will be.
> > 
> > to
> > | The Technical Committee offers no advice regarding sysvinit
> > | compatibility at this time after the jessie release.  There are too
> > | many variables at this point to know what the correct course of action
> > | will be.
> > 
> > (the empty line above is there by purpose, i.e. it also merges this
> > paragraph with the previous one)
> 
> I will transpose this into git.
> 
> As an observation from a native English speaker, the language is
> rather odd.  It is not conventional to have two time clauses next to
> each other like that.  I would suggest (but do not formally propose):
> 
>The Technical Committee offers no advice at this time regarding
>sysvinit compatibility after the jessie release.  There are too
>many variables at this point to know what the correct course of
>action will be.
> 
> Ie, move "at this time" to after "advice".

Thanks, accepted.



Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221152819.gw12...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Keith Packard]

Ian Jackson  writes:

> I've done so, thanks.

Looks good.

-- 
keith.pack...@intel.com


pgp6pLZwyhYsw.pgp
Description: PGP signature

Bug#727708: init system coupling etc.

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:37]:
> Andreas Barth writes ("Bug#727708: init system coupling etc."):
> > Russ Allbery (r...@debian.org) [140219 19:24]:
> > > How does this sound to you?
> > > 
> > > Packages should normally support the default init system on all
> > > architectures for which they are built.  There are some exceptional
> > > cases where lack of support for the default init system may be
> > > appropriate, such as alternative init system implementations,
> > > special-use packages such as managers for non-default init systems,
> > > and cooperating groups of packages intended for use with non-default
> > > init systems.  However, package maintainers should be aware that a
> > > requirement for a non-default init system will mean the package will
> > > be unusable for most Debian users and should normally be avoided.
> > 
> > Better but I think we should also point out that supporting different
> > architectures is a good thing.
> > 
> > So the first sentence rather as
> > | Packages should support as many architectures as reasonably possible,
> > | and they should normally ...
> > 
> > Also I'd like to amend the last sentence with ", and could constitute
> > an serious bug of the package." (which is a correct observation
> > according to the current RC policy)
> 
> Russ has already amended his text to say "Software should ...".  So
> when transposing your amendment onto Russ's new text, I have to decide
> between using your new text verbatim (effectively reverting that
> change), or treating your proposal as a request to change only the
> parts you are actually aiming at.
> 
> I'm going to do the latter because it appears to best reflect your
> intent.  This results in

Yes, that was the intention (basically it was a patch). Thanks.


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221152904.gx12...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Andreas Barth]

* Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]:
> Andreas Barth writes ("Bug#727708: init system coupling etc."):
> > Russ Allbery (r...@debian.org) [140219 19:24]:
> > So I propose to change the text:
> > >
> > > The Technical Committee offers no advice at this time on requirements
> > > or package dependencies on specific init systems after the jessie
> > > release.  There are too many variables at this point to know what the
> > > correct course of action will be.
> > 
> > to
> > | The Technical Committee offers no advice regarding sysvinit
> > | compatibility at this time after the jessie release.  There are too
> > | many variables at this point to know what the correct course of action
> > | will be.
> > 
> > (the empty line above is there by purpose, i.e. it also merges this
> > paragraph with the previous one)
> 
> Looking at Russ's draft, he has already made an effectively identical
> change.  Russ's wording is:
> 
> The Technical Committee offers no advice at this time on sysvinit
> support beyond the jessie release.  There are too many variables at
> this point to know what the correct course of action will be.
> 
> This differs from yours in the placement of "at this time" (see my
> previous mail) and in that it uses "beyond the jessie release" rather
> than "after the jessie release".  These don't seem to change the
> meaning much for me but improve the way it reads.
> 
> You may wish to adopt Russ's wording.

I do.


Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140221152930.gy12...@mails.so.argh.org

Bug#727708: init system coupling etc.

[Ian Jackson]

Andreas Barth writes ("Re: Bug#727708: init system coupling etc."):
> Ian Jackson (ijack...@chiark.greenend.org.uk) [140221 13:41]:
> > Looking at Russ's draft, he has already made an effectively identical
> > change.  Russ's wording is:
> > 
> > The Technical Committee offers no advice at this time on sysvinit
> > support beyond the jessie release.  There are too many variables at
> > this point to know what the correct course of action will be.
> > 
> > This differs from yours in the placement of "at this time" (see my
> > previous mail) and in that it uses "beyond the jessie release" rather
> > than "after the jessie release".  These don't seem to change the
> > meaning much for me but improve the way it reads.
> > 
> > You may wish to adopt Russ's wording.
> 
> I do.

Thanks, transferred to git.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.29369.227142.384...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Ian Jackson]

For Andi's version of Russ's text I have written this summary line
into the git repo:

  B  Advice: sysvinit compatibility in jessie and multi init, arch, support

The difference between Russ's (A) and Andi's (B) is precisely this:

 < Software should normally support the default init system on all
 ---
 > Software should support as many architectures as reasonably possible,
 > and it should normally support the default init system on all

If Russ does not accept this amendment then both A and B will be on
the ballot.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.29576.595770.419...@chiark.greenend.org.uk

Bug#727708: init system coupling etc.

[Russ Allbery]

Ian Jackson  writes:

> For Andi's version of Russ's text I have written this summary line
> into the git repo:

>   B  Advice: sysvinit compatibility in jessie and multi init, arch, support

> The difference between Russ's (A) and Andi's (B) is precisely this:

>  < Software should normally support the default init system on all
>  ---
>  > Software should support as many architectures as reasonably possible,
>  > and it should normally support the default init system on all

> If Russ does not accept this amendment then both A and B will be on
> the ballot.

I accept this amendment.

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/874n3swfez@windlord.stanford.edu

Bug#727708: init system coupling etc.

[Ian Jackson]

Russ Allbery writes ("Re: Bug#727708: init system coupling etc."):
> Ian Jackson  writes:
> > If Russ does not accept this amendment then both A and B will be on
> > the ballot.
> 
> I accept this amendment.

I have removed the unamended version from the git repo.  I've
transferred the option letter and summary from the unamended to the
amended version, as that seems less confusing and there is no longer a
need to distinguish what-as-A (which is now dropped) and what-was B
(which I'm now calling A) on the ballto summary.

Ian.


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
http://lists.debian.org/21255.36073.391696.922...@chiark.greenend.org.uk

Re: Bug#727708: init system coupling etc.

[Andreas Barth]

* Russ Allbery (r...@debian.org) [140212 19:00]:
> Packages should normally support the default Linux init system.  There

I would drop the word "Linux" here - Packages should support our
default init systems.

> are some exceptional cases where lack of support for the default init
> system may be appropriate, such as alternative init system
> implementations, special-use packages such as managers for non-default
> init systems, and cooperating groups of packages intended for use with
> non-default init systems.  However, package maintainers should be
> aware that a requirement for a non-default init system will mean the
> package will be unusable for most Debian users and should normally be
> avoided.

Also, I would think it appropriate if packages should (i.e. in case
appropriate patches are available) support other init systems, and not
depend on the default init systems.


> The Technical Committee offers no advice at this time on requirements
> or package dependencies on specific init systems after the jessie
> release.  There are too many variables at this point to know what the
> correct course of action will be.

I think we could just drop the whole paragraph.



Andi


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140213175859.ge16...@mails.so.argh.org

Re: Bug#727708: init system coupling etc.

[Russ Allbery]

Andreas Barth  writes:
> * Russ Allbery (r...@debian.org) [140212 19:00]:

>> Packages should normally support the default Linux init system.  There

> I would drop the word "Linux" here - Packages should support our default
> init systems.

That's a much stronger statement than we've made about support for the
non-Linux ports in the past, where they're treated at most like another
release architecture, which means that packages that have never worked on
that architecture are not expected to do so and packages that used to work
but stopped are sometimes removed from just that architecture rather than
ported depending on the situation.

So at least at a first pass, I'm not willing to drop the word Linux here.
I think the subsequent statement about merging patches and adding support
covers the situation.  Note that the sysvinit support statement later also
covers this through jessie, and I think it's appropriate to not make too
many statements about the situation after jessie at this time.

>> are some exceptional cases where lack of support for the default
>> init system may be appropriate, such as alternative init system
>> implementations, special-use packages such as managers for
>> non-default init systems, and cooperating groups of packages
>> intended for use with non-default init systems.  However, package
>> maintainers should be aware that a requirement for a non-default
>> init system will mean the package will be unusable for most Debian
>> users and should normally be avoided.

> Also, I would think it appropriate if packages should (i.e. in case
> appropriate patches are available) support other init systems, and not
> depend on the default init systems.

I think that's already covered in the paragraph after this one.

>> The Technical Committee offers no advice at this time on requirements
>> or package dependencies on specific init systems after the jessie
>> release.  There are too many variables at this point to know what the
>> correct course of action will be.

> I think we could just drop the whole paragraph.

Why do you want to drop it?

-- 
Russ Allbery (r...@debian.org)   


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/87y51etlgu@windlord.stanford.edu

Re: Bug#727708: init system coupling etc.

[Josh Triplett]

Ian Jackson wrote:
> Josselin Mouette writes ("Bug#727708: init system coupling etc."):
> > In all cases, it is unacceptable to put the burden of implementing
> > logind on non-systemd systems on maintainers of packages that just need
> > the logind interfaces. If it is not available, software such as gdm3
> > will depend, directly or indirectly, on systemd as PID 1, and that will
> > be all.
> 
> Firstly, I think the scenario where the required integration work is
> not done is unlikely.  But in that scenario, we have two choices:
>  (a) Effectively, drop all init systems other than systemd
>  (b) Effectively, drop GNOME

In this hypothetical scenario, suggesting that as an either-or implies
that *not* dropping GNOME, and instead having it exist in the archive
and depend on systemd, would effectively be dropping support for all
init systems other than systemd.  For that to be true, it would imply
that GNOME has such a critical level of importance in the distribution
that just having GNOME depend on systemd would make non-systemd inits
unusable.  If that were true, then (b) would fairly obviously not be an
option.  (Or to say that the other way around: if dropping GNOME were an
option, then it must not be important enough for its dependency on
systemd to be a problem.)  And if it *isn't* true, then there's no
forced dichotomy here: GNOME can depend on systemd, non-systemd inits
can continue to work fine on systems not running GNOME, and the world
doesn't end.

(Given the hypothetical scenario above, I'm going to ignore the issue
that this is about much more than just GNOME, and that there's a pile of
other relevant software planning to depend on logind or systemd in the
future.  Nonetheless, it's worth poking at the logic in the
hypothetical, since it seems generally applicable to more cases.)

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/20140214151322.GA20325@leaf

Re: Bug#727708: init system coupling etc.

[Svante Signell]

> * Russ Allbery (r...@debian.org) [140212 19:00]:
> > Packages should normally support the default Linux init system.  There
> 
> I would drop the word "Linux" here - Packages should support our
> default init systems.

If you do that then you have killed all non-linux architectures, is
that intentional? Debian is digging their own grave with respect to
Free Software (not not FOSS or FOS), why don't you align with M$soft,
Apple or especially RedHat :( Debian will just be a memory in a few
years, RedHat will be the solution for everybody (TM).


-- 
To UNSUBSCRIBE, email to debian-ctte-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/1392492790.3779.94.camel@PackardBell-PC