Bug#727708: On diversity

[Ian Jackson]

What is Debian ?  In one respect, Debian is an operating system.  And
of course in another respect Debian is a community.

But there are two other aspects of Debian's nature that have been very
important for our success:

* Debian is a forum for cooperation and technical development.

  Specifically Debian is a place where if you have some particular
  goals, you can find other like-minded people and collaborate with
  them to achieve them.  Even if others in the project don't
  necessarily think those goals are important.

  (I remember when I was very dismissive of the idea that
  cross-building Debian would ever be feasible or useful.  I was
  wrong; but more importantly, the fact that I - and some others -
  thought that way was no blocker to those who wanted to the work.)

* Debian, as a piece of software, tries to be all things to all
  people (within reason).

  That is, the software we ship is both a working system, but also a
  template, including all the pieces, for making your own operating
  system, the way you want it.

  This may mean that everything we do is slightly less slick in the
  "usual" case, but I think the value of that flexibility massively
  outweighs the costs.  If others want to derive from us and make
  more specific choices then that's good, but we should truly aim to
  be as universal an upstream distro as we can be.

These two things are very closely related; arguably they are aspects
of the same principles.

We are reluctant to commit to any particular way of doing things;
reluctant to declare other people's goals out of our scope; and
reluctant to tell our users and downstreams that things Will Be Done
in a particular way.  We make those firm choices only when absolutely
necessary.

This flexibility and tolerance for divergence has made Debian an
extremely attractive target for everyone to work within, work on, and
derive from.  I think it has been key to the success of the project.

Of course all this diversity brings substantial distribution-wide
costs.  We do regularly struggle with issues where a particular goal
imposes costs on packages, and we try to minimise that.

But the flipside is that this acceptance for others' goals and choices
brings those people into our community, providing us with the manpower
we have used to build the best, the most flexible, and the most
derived-from Free Software operating system in the world.

I passionately believe that we need to retain this aspect of our
community, even if that causes us extra work; and even if it causes
friction with those who would like to make the world nice and simple
by only supporting certain goals, certain use cases, or certain
software.


Now let me apply that to init systems:

If you think that the difference between upstart and systemd, or
between either of those and systemd, is not important, then perhaps
you could conclude that it was OK to impose a particular decision on
all of our users and all of our downstreams.

But I think the differences /are/ important.

That means that we need to be the venue where systemd proponents, and
upstart proponents, and openrc proponents, can make the best system
they can.

Naturally that will involve some compromises.  That's an unavoidable
cost of trying to be the best place for everyone to pursue their own
goals.

I think in this case those compromises are absolutely essential.  Not
just from a technical point of view because of the advantages of one
system over another.  But also to ensure that Debian continues to be
the place where serious and dynamic people come to do their stuff.

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/21208.7280.122388.659...@chiark.greenend.org.uk

Bug#727708: On diversity

[Ian Jackson]

Ian Jackson writes ("On diversity"):
> If you think that the difference between upstart and systemd, or
> between either of those and systemd, is not important, then perhaps
  ^^^
Should read sysvinit.  Bah, etc.

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/21208.7415.18252.152...@chiark.greenend.org.uk

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
> * Debian is a forum for cooperation and technical development.

> * Debian, as a piece of software, tries to be all things to all
>   people (within reason).

> This flexibility and tolerance for divergence has made Debian an
> extremely attractive target for everyone to work within, work on, and
> derive from.  I think it has been key to the success of the project.

I think the divergence has gone too far in things like non-Linux ports.
They have had an overall negative effect on people working on Linux
within Debian and people creating derivatives.


> I passionately believe that we need to retain this aspect of our
> community, even if that causes us extra work; and even if it causes
> friction with those who would like to make the world nice and simple
> by only supporting certain goals, certain use cases, or certain
> software.
> 
> 
> Now let me apply that to init systems:

Even if you start from the assumption that diversity is positive, you
can't justify support for any particular system without analyzing costs
and possible alternative goals. Is support for multiple init systems
more important than having a good SELinux policy for each package? Being
able to compile packages with several different compilers? Just fixing
more known bugs in existing packages? You could come up with hundreds of
possible goals that would all have at least some positive effect; just
saying that diversity is good can't allow you to pick some and reject
others.


> If you think that the difference between upstart and systemd, or
> between either of those and systemd, is not important, then perhaps
> you could conclude that it was OK to impose a particular decision on
> all of our users and all of our downstreams.

I think there are important differences: upstart is significantly worse
than systemd in several areas.

> But I think the differences /are/ important.

Do you actually believe that upstart has some nontrivial technical
advantages over systemd, such that it would be a noticeably better
alternative even when considering only some specific use case? IIRC you
did not identify any when saying you preferred upstart earlier, and
mainly based your opinion on the assumption that upstart would be more
likely to get ported.

Even the upstart proponents do not seem to have significant arguments
about upstart having better functionality, and there don't seem to be
all that many people who would have a reasonably informed opinion that
upstart would be technically better even for just their particular use.
To me it looks like the main reason Upstart is still alive at all is
that Ubuntu don't want to pay the cost of the conversion to the better
system and don't want to admit that "their" alternative was inferior.

If the differences are mainly just "it's worse" rather than tradeoffs
where each software has clear technical advantages, it's unlikely
diversity would give any significant benefits.


> That means that we need to be the venue where systemd proponents, and
> upstart proponents, and openrc proponents, can make the best system
> they can.

I do not believe it is possible to create such a venue. The result of
the kind of "everything must be supported" policies you seem to favor
would be a venue where nobody is able to create a system they would be
happy with. Or possibly only sysvinit/openrc proponents would be happy
with, if everything is dumbed down to the level where those systems can
handle it.

> Naturally that will involve some compromises.  That's an unavoidable
> cost of trying to be the best place for everyone to pursue their own
> goals.

"The best place for everyone to pursue their own goals" is
self-contradictory. You need to choose whose goals matter most; if you
don't, it'll require so many compromises that it's not only not "the
best place" for most, it outright sucks. Everyone can maintain their own
leaf package, but not everyone can design how boot and service
management should work.

> I think in this case those compromises are absolutely essential.  Not
> just from a technical point of view because of the advantages of one
> system over another.  But also to ensure that Debian continues to be
> the place where serious and dynamic people come to do their stuff.

Debian has been successful in some ways, but I don't think it is "the
place where serious and dynamic people come to do their stuff". For
example, none of the newer init systems come from Debian itself; I think
that reflects how hard it is to create the kind of progress I'd
associate with the word "dynamic" within Debian. Debian mainly
integrates serious new developments long after they've been used
elsewhere.


-- 
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/1389919551.4304.123.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Russ Allbery]

Uoti Urpala  writes:

> I think the divergence has gone too far in things like non-Linux ports.
> They have had an overall negative effect on people working on Linux
> within Debian and people creating derivatives.

I have to take exception to this.  There has been a great deal of
*concern* from people over the past two years that the non-Linux ports
*might* have a negative effect on Linux in the context of this particular
discussion.  But, in the meantime, the non-Linux porters have been
first-class Debian contributors over the years.  They have not
substantially gotten in the way of Debian's processes, certainly no more
than any Linux port to a more obscure architecture, and they have
contributed a great many improvements to our software.

For example, I think special thanks should go to the Hurd porters for
extended, thankless work on removing static buffers from the code in the
archive.  They were doing so because some of the constants used to size
those buffers are not portable to the Hurd, but using static buffers to
store paths and related strings is often incorrect regardless of its
portability, and can even be a security issue depending on how the code is
written.  The Hurd porters have provided reasonable patches that can go
back to upstream and result in objectively more robust software.  I have
gotten a steady stream of solid and thoughtful patches from the Hurd
porters for years as a Debian package maintainer, and I appreciate that
work.

-- 
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/87txd35snd@windlord.stanford.edu

Bug#727708: On diversity

[Thorsten Glaser]

Uoti Urpala dixit:

>They have had an overall negative effect on people working on Linux
>within Debian and people creating derivatives.

Besides what Russ said: Debian isn’t about Linux.
Debian is the universal operating system.

bye,
//mirabilos
-- 
18:47⎜ well channels… you see, I see everything in the
same window anyway  18:48⎜ i know, you have some kind of
telnet with automatic pong 18:48⎜ haha, yes :D
18:49⎜ though that's more tinyirc – sirc is more comfy


--
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.1401170846190.9...@herc.mirbsd.org

Bug#727708: On diversity

[Ondřej Surý]

On Fri, Jan 17, 2014, at 1:45, Uoti Urpala wrote:
> On Thu, 2014-01-16 at 17:52 +, Ian Jackson wrote:
> > * Debian is a forum for cooperation and technical development.
> 
> > * Debian, as a piece of software, tries to be all things to all
> >   people (within reason).
> 
> > This flexibility and tolerance for divergence has made Debian an
> > extremely attractive target for everyone to work within, work on, and
> > derive from.  I think it has been key to the success of the project.
> 
> I think the divergence has gone too far in things like non-Linux ports.
> They have had an overall negative effect on people working on Linux
> within Debian and people creating derivatives.

Could you please state your affiliation with Debian and the real work
you have done on Linux within Debian?

All I have seen and can find from you is the flaming in the lists. So I
suggest that unless you do a work within Debian you should not voice
your opinions for other Debian Developers. E.g. speak about yourself and
not about "people". You are not the voice of the people and definitely
not a voice of Debian people. Preferably just refrain from adding more
of *your* opinions into this bug report.

Thank you,
-- 
Ondřej Surý 
Knot DNS (https://www.knot-dns.cz/) – a high-performance DNS server


--
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/1389950502.25931.71910613.5d55a...@webmail.messagingengine.com

Bug#727708: On diversity

[Ihar Filipau]

Uoti Urpala wrote:
> Even the upstart proponents do not seem to have significant arguments
> about upstart having better functionality, and there don't seem to be
> all that many people who would have a reasonably informed opinion that
> upstart would be technically better even for just their particular use.

I followed the discussion from the beginning and I'd like to comment on that.
My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
fresh in my memory.

Though I do not have strong personal preference for one or another, the Ubuntu
(as an OS based on upstart) left much much better impression than the Fedora (as
an OS based on systemd). Looking at the both of them over period of two days
showed several cardinal differences. I'll narrow it down to three, first one
addressing "what's better in upstart?".

1. "upstart" is a highly configurable init system, while "systemd" hardcodes
most of the nuts and bolts in the 32 shipped executables. I spent one days
going through the upstart's setup on Ubuntu: lots of stuff, lots of non-trivial
inter-connections. I needed only two hours to review systemd setup. Because
every interesting and important bit was just a call of the special systemd
binary. Most (but not all) of the special binaries have man pages, but only few
of the helper binaries actually provide any customization capability.
Again: systemd on Fedora 10 is compromised of more than *30* binaries
(not counting: systemd binary itself, the generators and the admin utilities).


So here you go. The advantage of the upstart, is that if you need to tweak the
boot of your system, you can do it right there, with the text editor, by
changing the .conf files or the shell scripts. While with the systemd, you have
to patch the sources, recompile and reinstall. Because literally everything
is hardcoded in some special systemd binary.
(Coming from the embedded systems, to me personally that is a biggie.)

2. "upstart" was not designed or intended to be a SMF (service management
facility), while "systemd" was.

I think it is insincere of upstart proponents to even advertise it as such. On
Ubuntu, upstart effectively ends its work by calling the
`/etc/init.d/rc $RUNLEVEL`. (What IMO means it might make sense to look into
integration of upstart with OpenRC. Orthogonality of the two should mean few
conflicts.)

On the other side of the fence. As I see it, it is only a coincidence that
"systemd" is also an init system. To me it was clearly designed from ground up
as SMF: boot and initialization were only afterthought. That's why the magic
binaries, because the initialization, an event driven process, simply doesn't
fit into the systemd "everything is a service" model.


3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
flat 0m35s. That was pretty dumbfounding realization, especially after finding
that Fedora has only few sysvinit scripts - and Ubuntu has almost all services
started by the sysvinit shell scripts.


Summary. Since the discussion about the init system choice IMO went on for too
long, I can only recommend to repeat my experiment: create two VMs - VirtualBox
is available right from the Debian repos ;-) - and install Fedora 20 and Ubuntu
13.10. See the differences for yourself. Experience the differences for
yourself.

Regards,
and good luck reaching the decision.


P.S. bugs.debian.org doesn't seem to let my e-mails through.
Two attempts to subscribe to the bug went nowhere.
Let's see if this message is luckier.


-- 
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/cad08gxk9dvnr3gr_nlzxwjvnagnk1jxyje+uca9o++rxuty...@mail.gmail.com

Bug#727708: On diversity

[Josselin Mouette]

Le vendredi 17 janvier 2014 à 08:47 +, Thorsten Glaser a écrit :
> Besides what Russ said: Debian isn’t about Linux.
> Debian is the universal operating system.

Just because you don’t understand that sentence doesn’t mean you can use
it to justify whatever convoluted position of yours.

An operating system is universal if it can be used for all purposes.
An operating system that supports several kernels and init systems, but
all incompletely, letting the user choose between different ways of
failing to boot, is not universal. It is irrelevant to any serious use
case.

-- 
.''`.  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/1389971621.21140.4.camel@tomoe

Bug#727708: On diversity

[Christoph Anton Mitterer]

On Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote:
> Just because you don’t understand that sentence doesn’t mean you can use
> it to justify whatever convoluted position of yours.
I wonder who really doesn't understand here...

> An operating system is universal if it can be used for all purposes.
> An operating system that supports several kernels and init systems, but
> all incompletely, letting the user choose between different ways of
> failing to boot, is not universal. It is irrelevant to any serious use
> case.
... since which king is then,... who decides which way/init
system/kernel/etc... is the "right", the universal, for all people?


Cheers,
Chris.


smime.p7s
Description: S/MIME cryptographic signature

Bug#727708: On diversity

[Ian Jackson]

Christoph Anton Mitterer writes ("Bug#727708: On diversity"):
> On Fri, 2014-01-17 at 16:13 +0100, Josselin Mouette wrote:
> > Just because you don’t understand that sentence doesn’t mean you can use
> > it to justify whatever convoluted position of yours.
> I wonder who really doesn't understand here...

I think this discussion is sterile.  The "universal operating system"
phrase is a slogan.  It's not sensible to go into a detailed semantic
analysis of it.  If Josselin doesn't find it convincing then arguing
over the meaning of "universal" or whatever isn't helpful.

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/21209.21448.808139.167...@chiark.greenend.org.uk

Bug#727708: On diversity

[Christoph Anton Mitterer]

On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote:
> The "universal operating system"
> phrase is a slogan.
Sure it is, but that slogan actually stands for some important
principles in the open source world... like not to "force" stuff upon
users... and allowing many different things to happily co-exist.
Open source is also a lot about freedom (not only that of developers but
also that of users)

Now looking at the GNOME-background,... there are surely people who'd
say that these folks have sometimes forgotten a bit those ideals.


Anyway... I guess that's off topic to this discussion (sorry for
that)... except perhaps that part,... that neither choice for an
init-system should restrict the freedom of others (k/freebsd, hurd, the
guys who like another init-system more) more than absolutely necessary.



Cheers,
Chris.


-- 
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/1389974931.7103.5.ca...@heisenberg.scientia.net

Bug#727708: On diversity

[Russ Allbery]

Christoph Anton Mitterer  writes:
> On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote:

>> The "universal operating system" phrase is a slogan.

> Sure it is, but that slogan actually stands for some important
> principles in the open source world... like not to "force" stuff upon
> users... and allowing many different things to happily co-exist.

It does for you.  It doesn't necessarily for everyone, and since there's
no meat to the slogan beyond that one sentence, there's nothing there to
persuade anyone that your interpretation is correct and someone else's is
incorrect.

I agree with Ian: there's no real point in using this as a basis for an
argument, since it's not going to convince people.  I think there are
other, better arguments in favor of supporting a variety of goals and
projects in Debian.

> Now looking at the GNOME-background,... there are surely people who'd
> say that these folks have sometimes forgotten a bit those ideals.

Again, please extend to your fellow developers the courtesy of assuming
that they understand all of this background just as well as you do.
People can disagree with each other without one of them being forgetful,
or disagreeing with freedom, or possessing some other character flaw.

-- 
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/8738kmecll@windlord.stanford.edu

Bug#727708: On diversity

[Adrian Bunk]

On Fri, Jan 17, 2014 at 05:08:51PM +0100, Christoph Anton Mitterer wrote:
> On Fri, 2014-01-17 at 16:01 +, Ian Jackson wrote:
> > The "universal operating system"
> > phrase is a slogan.
> Sure it is, but that slogan actually stands for some important
> principles in the open source world... like not to "force" stuff upon
> users... and allowing many different things to happily co-exist.
> Open source is also a lot about freedom (not only that of developers but
> also that of users)
>...

This is a common misconception:

There is no such principle, and Open Source does not turn the developers 
who (often in their spare time) work on the software into slaves of 
their users. The exact opposite is true, and the developers who do the 
work have the freedom to force whatever they want on the users of their 
software.

Among the freedoms Open Source gives to all users the relevant one is 
actually the right to fork: If you don't like a policy decision of an 
Open Source project, you can always create a fork that works exactly
the way you envision it.

This is quite fair in giving the power of making decisions not to the 
users who scream loudest, but to the people who actually do the work.

And for Debian the Technical Committee is the instance to make such 
decisions on behalf of the whole project.

> Cheers,
> Chris.

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/20140117174137.ga30...@bunk.dyndns.info

Bug#727708: On diversity

[Uoti Urpala]

On Fri, 2014-01-17 at 16:08 +0100, Ihar Filipau wrote:
> Uoti Urpala wrote:
> > Even the upstart proponents do not seem to have significant arguments
> > about upstart having better functionality, and there don't seem to be
> > all that many people who would have a reasonably informed opinion that
> > upstart would be technically better even for just their particular use.
> 
> I followed the discussion from the beginning and I'd like to comment on that.
> My own comparison of systemd vs. upstart (Fedora 20 vs. Ubuntu 13.10) is still
> fresh in my memory.

Your comparison does not look very informed, see below.


> 1. "upstart" is a highly configurable init system, while "systemd" hardcodes
> most of the nuts and bolts in the 32 shipped executables. I spent one days

Your "hardcodes" is wrong: systemd ships with helper executables and a
default boot setup which uses those, but they're not hardcoded and you
can use something else if you have a reason to.

> So here you go. The advantage of the upstart, is that if you need to tweak the
> boot of your system, you can do it right there, with the text editor, by
> changing the .conf files or the shell scripts. While with the systemd, you 
> have

I strongly disagree that using shell more as an implementation language
would be a good thing. But out of the things in your post I think this
is the closest to a not-factually-incorrect personal preference someone
could have for upstart: some people could prefer working in shell only.
However, this isn't really a comparison of the init systems themselves
so much as a comparison of the default boot setups shipped with the
inits. Even if you decide that almost every program running on your
system should be implemented in shell only, you could still use systemd
to start those programs, though you'd need to change more of the default
configuration if you wanted to avoid starting anything non-shell at
boot.


> 2. "upstart" was not designed or intended to be a SMF (service management
> facility), while "systemd" was.
> 
> I think it is insincere of upstart proponents to even advertise it as such. On

> On the other side of the fence. As I see it, it is only a coincidence that
> "systemd" is also an init system. To me it was clearly designed from ground up
> as SMF: boot and initialization were only afterthought. That's why the magic
> binaries, because the initialization, an event driven process, simply doesn't
> fit into the systemd "everything is a service" model.

This is nonsense. Technically, the choice of implementation language for
the binaries/scripts and the event/dependency model are completely
orthogonal. This means your last sentence is completely wrong. It's also
not plausible as a historical fact that boot would have been an
"afterthought".


> 3. Boot times. Though systemd was supposed to improve the boot time, Fedora 20
> VM on my rig needs 1m5s-1m15s to start - while Ubuntu 13.10 VM always timed
> flat 0m35s. That was pretty dumbfounding realization, especially after finding

Other people have Fedora booting a lot faster. There are lots of reasons
that could make boot slow other than inherent problems with the init
system, so if you haven't done any analysis of the causes of the
slowness, this does not really tell anything.


-- 
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/1389981988.4304.154.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Anthony Towns]

On 17 January 2014 03:52, Ian Jackson  wrote:
> What is Debian ?  In one respect, Debian is an operating system.  And
> of course in another respect Debian is a community.
> * Debian is a forum for cooperation and technical development.
> * Debian, as a piece of software, tries to be all things to all
>   people (within reason).

So the original message referring this to the tech ctte was about
deciding on "the default init system". Honestly, that seems like the
least interesting part of this discussion to me; and I wonder if the
ctte shouldn't consider answering some different, but related question
that more directly addresses issues like packages depending on cgroups
or logind. Something like:

 a) maintainers should be aware cgroups is a Linux-only feature; if
their package requires the use of cgroups to be usable it should be
configured to not build for non-Linux architectures.

 b) maintainers should be aware systemd relies heavily on cgroups, and
thus should be aware that requiring use of a systemd unit file for
startup will likewise require their package to be configured to not
build for non-Linux architectures.

 c) logind or an equivalent service implementing the freedesktop.org
systemd/logind api should be available under all supported init
systems and architectures in Debian. It should be provided via a
virtual package "fdo-logind" and packages (such as desktop managers)
expecting logind to be available should Depend on fdo-logind

 d) [are packages likely to start depending on
localed/hostnamed/timedated/machined/??? in the same way as logind
such that it would need to be available outside systemd for upstart to
be a useful init?]

 e) no init system in Debian should be marked as Essential:yes, or
depended upon by any Essential:yes or Priority:required package except
through the virtual package "init-system". All init packages should
Provide: and Conflict: init-system. base-files should Depend:
init-system.

 f) all init systems Providing the init-system virtual package must
support packages providing sysv style init scripts via update-rc.d.

 g) packages that do not work with sysv must declare a Depends: on the
init systems they do support, eg upstart | systemd

 h) having examined the various current available init systems, the
tech ctte considers [OpenRC] to be the best available init
implementation at present, and so determines that the relevant
maintainers, including the installer team and ftpmasters se it as the
default init-system for new Debian installs. This decision becomes
vacant should a general resolution specifying an alternative init
system as the default pass with a simple majority prior to jessie's
release.

 i) all these decisions revert to advisory opinions after the release
of jessie, and may then be changed by the usual methods of consensus
driven policy development, and maintainer decisions, or by referring
the issue to the tech ctte again.

I think (a) and (b) are pretty non-controversial. (c) and (d) are
required if we want to deal with new GNOME stuff and anything other
than systemd probably, and don't seem very hard to either do or
document. (e), (f) and (g) seem like a fairly straightforward of
allowing for multiple init systems in Debian. I think something like
(i) might be a good way of sunsetting tech ctte decisions so if
there's an actual consensus in future, there's no need to get a
pro-forma vote from the ctte to make changes in future. YMMV of
course.

In my ideal world, the tech ctte would work out good answers to all
the bits above except (h) and get those added to policy, then propose
various options for (h) as a GR themselves, with well argued
rationales for each of the options along the lines of what's already
been posted to the list. How much that conflicts with the "No detailed
design work" portion of the ctte's mission statement is up for debate
though. Why you'd have a *technical* committee and forbid them making
sure the "details" are right doesn't make a lot of sense to me though.
Fortunately I'm not on the tech ctte list, so I can look into details
all I like ;)

Cheers,
aj


-- 
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/cajs_lcxtps1xdy6owf6eqwz5jwujccj0sio8kadakqwv2k8...@mail.gmail.com

Bug#727708: On diversity

[Josselin Mouette]

Le lundi 20 janvier 2014 à 01:17 +1000, Anthony Towns a écrit :
>  c) logind or an equivalent service implementing the freedesktop.org
> systemd/logind api should be available under all supported init
> systems and architectures in Debian. It should be provided via a
> virtual package "fdo-logind" and packages (such as desktop managers)
> expecting logind to be available should Depend on fdo-logind

I think this is the right approach for logind. This way, the only
implementation would be systemd as PID1, but if the proponents of
alternative init systems actually wrote another implementation, it would
be available.

The one thing that is not handled this way is versioning, because later
versions of GNOME could require newer APIs.


I also have to insist that GNOME 3.10+ *needs* a working logind even for
basic functionality, and that starting with v205, logind *needs* systemd
as PID 1. You might disagree with the implementation details that lead
to this situation, but you should not expect either of these facts to
change before jessie.

This is why the idea to fully support more than one init system is never
going to hold.
  * Either we upgrade systemd to a recent version and have (at
least) GNOME depend on systemd as PID 1.
  * Either we keep systemd at version 204, we don’t use it as PID 1
(because it would be madness to be so lagging in versions), we
find people willing to do long-term maintenance on the
components we use (probably Canonical), and we have this
discussion again for the next release when the reverse
dependencies require newer versions of systemd.
  * Either we remove systemd from Debian with all its reverse
dependencies (including at least GNOME).

Currently I have no idea of how (and by whom) any other option than
those three would be implemented, making any decision stating otherwise
untenable.

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/1390155797.29928.17.camel@tomoe

Bug#727708: On diversity

[Steven Chamberlain]

On 19/01/14 18:23, Josselin Mouette wrote:
> I also have to insist that GNOME 3.10+ *needs* a working logind even for
> basic functionality, and that starting with v205, logind *needs* systemd
> as PID 1.

Sorry if this has been already answered, but if that's the opinion of
GNOME maintainers, isn't this okay (starting in jessie or jessie+1)?
Have GNOME depend on logind and indirectly systemd-as-pid1, and just be
unavailable on other init systems.  Much of GNOME would thus become
linux-any and be removed from GNU/kFreeBSD, but there are still other
desktop environments to choose from.

That is, until/unless someone else can provide an alternate
implementation of logind, or whatever else is needed, then it would
become installable/usable again.

Regards,
-- 
Steven Chamberlain
ste...@pyro.eu.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/52dc1c3a.6010...@pyro.eu.org

Bug#727708: On diversity

[Adrian Bunk]

On Sun, Jan 19, 2014 at 07:23:17PM +0100, Josselin Mouette wrote:
>...
> I also have to insist that GNOME 3.10+ *needs* a working logind even for
> basic functionality,
>...

Can you elaborate on where exactly upstream GNOME 3.10 has a hard 
dependency on logind, and no alternative ConsoleKit codepath that
could be used instead?

> Cheers,

Thanks
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/20140119185642.gn30...@bunk.dyndns.info

Bug#727708: On diversity

[Steve Langasek]

On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:

>  d) [are packages likely to start depending on
> localed/hostnamed/timedated/machined/??? in the same way as logind
> such that it would need to be available outside systemd for upstart to
> be a useful init?]

GNOME certainly uses these interfaces already.  Whether they should be
considered a "dependency" or not is probably something that should be left
to the maintainers' discretion.  But I think they should certainly be
handled the same way as logind, generally - with a dependency on some
virtual package that other implementations could provide (or that can be
provided by a binary package from systemd source that doesn't depend on pid
1 - since these dbus services all work fine on non-systemd systems, and
there's no technical reason that should ever change given the function of
the services in question).

> I think (a) and (b) are pretty non-controversial. (c) and (d) are
> required if we want to deal with new GNOME stuff and anything other
> than systemd probably, and don't seem very hard to either do or
> document. (e), (f) and (g) seem like a fairly straightforward of
> allowing for multiple init systems in Debian. I think something like
> (i) might be a good way of sunsetting tech ctte decisions so if
> there's an actual consensus in future, there's no need to get a
> pro-forma vote from the ctte to make changes in future. YMMV of
> course.

For my part I think this is generally a good idea, but I have the impression
that at least Russ would be strongly opposed to this because it's too
prescriptive.  Probably not much sense in fleshing out such a resolution if
there's not a consensus 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: On diversity

[Russ Allbery]

Steve Langasek  writes:
> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:

>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
>> required if we want to deal with new GNOME stuff and anything other
>> than systemd probably, and don't seem very hard to either do or
>> document. (e), (f) and (g) seem like a fairly straightforward of
>> allowing for multiple init systems in Debian. I think something like
>> (i) might be a good way of sunsetting tech ctte decisions so if there's
>> an actual consensus in future, there's no need to get a pro-forma vote
>> from the ctte to make changes in future. YMMV of course.

> For my part I think this is generally a good idea, but I have the
> impression that at least Russ would be strongly opposed to this because
> it's too prescriptive.  Probably not much sense in fleshing out such a
> resolution if there's not a consensus for it.

I think this is all great work to do.  I'm just dubious about enforcing it
with a technical committee decision.  This is the sort of thing that I was
expecting to need to do on the Policy front once we have a decision.  I
think that's the right forum for drilling into the details.

-- 
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/87txczff8c@windlord.stanford.edu

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery  wrote:
> Steve Langasek  writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>>> I think (a) and (b) are pretty non-controversial. (c) and (d) are
>>> required if we want to deal with new GNOME stuff and anything other
>>> than systemd probably, and don't seem very hard to either do or
>>> document. (e), (f) and (g) seem like a fairly straightforward of
>>> allowing for multiple init systems in Debian. I think something like
>>> (i) might be a good way of sunsetting tech ctte decisions so if there's
>>> an actual consensus in future, there's no need to get a pro-forma vote
>>> from the ctte to make changes in future. YMMV of course.
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to this because
>> it's too prescriptive.  Probably not much sense in fleshing out such a
>> resolution if there's not a consensus for it.
> I think this is all great work to do.  I'm just dubious about enforcing it
> with a technical committee decision.  This is the sort of thing that I was
> expecting to need to do on the Policy front once we have a decision.  I
> think that's the right forum for drilling into the details.

Personally, I'm still not really clear on where the ctte is leaning
wrt supporting multiple init systems; if the idea is that [OpenRC]
becomes the new default, and declares itself as Essential:yes, and the
Debian maintainers of [systemd and upstart] say "okay, I give up, I'm
going to work on [OpenRC] now", it doesn't seem like there'd be much
need for policy work. Obviously, switch the init systems around as
appropriate. I believe I've seen comments along those lines from both
systemd and upstart maintainers should upstart or systemd be chosen as
the default, but maybe I'm mistaken. I'm pretty sure I've seen
numerous comments that Debian should only support one init system (per
kernel, at any rate), which would make the Essential:yes part make
sense. To me that seems like it would be a bad outcome (even if we
adopted upstart everywhere and abandoned sysvrc, systemd and openrc
entirely; it would still make it unduly difficult to experiment with
the next next-generation init systems in a Debian environment). I'd
expect the tech ctte's decision to be prescriptive enough that it's
clear what non-default-init-system maintainers and users should do,
post-apocalypse, I guess.

On a practical note, having a quick look at the policy list, it seems
like that's not actually crazy active/responsive at present either
(long overdue updates to menu policy and triggers documentation are
the only topics this month?), so relying on -policy for detail work
doesn't seem like it would actually work out in a timely fashion?

Honestly, I was a bit surprised that Steve thinks the above's a good
idea, given I wrote it from the (my) perspective of wanting to support
multiple init systems within Debian; and my understanding is his
opinion is that that's kind-of nuts. I think that's pretty great
through, especially in that it affirms my naive faith that drilling
down into technical details is a good way of achieving consensus
amongst people with very different goals and political/philosophical
stances... ;)

Cheers,
aj

-- 
Anthony Towns 


-- 
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/cajs_lcw-vs6mi7qk-gvaqayqsu49dqbgojpa79gwhzbm6jt...@mail.gmail.com

Bug#727708: On diversity

[Russ Allbery]

Anthony Towns  writes:

> To me that seems like it would be a bad outcome (even if we adopted
> upstart everywhere and abandoned sysvrc, systemd and openrc entirely; it
> would still make it unduly difficult to experiment with the next
> next-generation init systems in a Debian environment). I'd expect the
> tech ctte's decision to be prescriptive enough that it's clear what
> non-default-init-system maintainers and users should do,
> post-apocalypse, I guess.

For as long as they're interested in making the effort, try to get as many
packages as possible supported under their init system, particularly in
advance of the point at which we might start dropping sysvinit scripts
that currently provide the common denominator across all the systems.
Obviously, to the extent that this can reuse work done for the default
init system, that's going to make this much easier.  That means that
implementing the key integration features of the default init system will
make things much easier (for example, things like the notification
protocol, non-forking daemon startup, and possibly socket activation).

It's going to be particularly important to have good docs for maintainers
to write configuration for the non-default init system, since a lot of
maintainers aren't going to be able to easily test, so you want people to
be able to write things that work without a lot of debugging.  Obviously,
that includes Policy.

> On a practical note, having a quick look at the policy list, it seems
> like that's not actually crazy active/responsive at present either (long
> overdue updates to menu policy and triggers documentation are the only
> topics this month?), so relying on -policy for detail work doesn't seem
> like it would actually work out in a timely fashion?

Policy is in general not horribly healthy right now, but as I mentioned in
passing earlier in this huge thread, I'm committing to shephard the Policy
work for this decision through and try to help with the documentation and
specifics.  I can't do that and participate in this discussion at the same
time, though, since this is basically eating all my Debian time at the
moment.

-- 
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/87bnz7fap3@windlord.stanford.edu

Bug#727708: On diversity

[Steve Langasek]

On Mon, Jan 20, 2014 at 03:51:20PM +1000, Anthony Towns wrote:
> Honestly, I was a bit surprised that Steve thinks the above's a good
> idea, given I wrote it from the (my) perspective of wanting to support
> multiple init systems within Debian; and my understanding is his
> opinion is that that's kind-of nuts. I think that's pretty great
> through, especially in that it affirms my naive faith that drilling
> down into technical details is a good way of achieving consensus
> amongst people with very different goals and political/philosophical
> stances... ;)

:)

So to expand on where I'm coming from:  I think that it's important to
choose a default for jessie, and that it's important that this not be
sysvinit; and I think whatever init system we choose for jessie will wind up
having a significant boost in momentum within Debian which will give it
staying power for a long time to come, and the non-default init systems will
receive little if any attention.  But I don't think the TC decision should
be a *permanent* one; as you say, there's always a next next-generation to
think about.  So I think we shouldn't have any particular init system marked
as Essential: yes.  Indeed, sysvinit being marked Essential: yes was an
obstacle for upstart in Debian for quite a while; less so for systemd
because the systemd maintainers made the expedient - but IMHO technically
undesirable - decision to split all conflicting files into a separate
package.

So that's to e).  f) is the sort of thing I think should be time limited to
jessie; g) seems obviously correct as far as it goes, but I think we might
quibble on the details of what packages are allowed to do this and why,
because one of the important features of Debian is that you can install
nearly anything from the archive together on the same system.  Having
packages with mutually incompatible dependencies on specific init systems
would undermine this badly.

And c) and d) are completely aligned with what I've been arguing (perhaps
poorly) that should be done with logind integration, because it's relevant
even if we don't adopt upstart as the default, as long as we want to have
non-Linux ports going forward.

So while I don't want to encourage the project to divide its efforts across
multiple different init systems in jessie, I think the particular points you
raise here are good ones, and I would only quibble on some of the minor
details.

-- 
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: On diversity

[Pacho Ramos]

Have you think in having a Systemd team in Debian taking care of
providing support for its packages? That way, people should be able to
run it in some weeks and, as soon as existing init.d files are not
dropped, people won't lose support for that (apart of the cases like
GNOME that needs systemd running to work better)

That is the way we went on Gentoo and looks to work well: we started
from openRC only setup, when we needed better systemd support along our
portage tree due Gnome 3.8 requirements, we (Gentoo systemd team)
started to work in adding systemd support and unit files to our
packages, that way, our maintainers weren't forced to run systemd to
test their unit files work fine and test both systems themselves.

We now have a working Systemd setup and, for our BSD ports, people still
have openRC support (even not being able to run all features of GNOME
but... much more cannot be done on that since
http://www.gentoo.org/proj/en/desktop/gnome/openrc-settingsd.xml isn't
enough to not lose any features since 3.8)

>From my perspective, I would support both setups: systemd (due it being
required by more upstreams along the time, and, *in my personal
opinion*, I think it works pretty well) and another one for BSDs and
people hating so much Systemd (I would choose openRC... but since I come
from Gentoo and know about it more than about upstart... ;))


-- 
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/1390202113.24148.182.camel@belkin5

Bug#727708: On diversity

[Tollef Fog Heen]

]] Steve Langasek 

> GNOME certainly uses these interfaces already.  Whether they should be
> considered a "dependency" or not is probably something that should be left
> to the maintainers' discretion.  But I think they should certainly be
> handled the same way as logind, generally - with a dependency on some
> virtual package that other implementations could provide (or that can be
> provided by a binary package from systemd source that doesn't depend on pid
> 1 - since these dbus services all work fine on non-systemd systems, and
> there's no technical reason that should ever change given the function of
> the services in question).

I'm willing to look at adding virtual packages for those once we
actually see alternative implementations happening.  Adding them because
somebody might, maybe, possibly add them somewhere down the line sounds
premature.

As for whether they should work with non-pid1 or not, it's also a
question about what we (the systemd maintainers) want to support.  The
daemons currently don't require systemd as pid1, but given all the flak
over maybe making logind require systemd as pid1 there is a very strong
incentive to not make those implementations work with another init.  The
CTTE here and in the past (see NM) views regressions as much more
serious than lacking implementations.

I think this is pretty sad and gives maintainers perverse incentives,
since there's not really any graceful way to say «this will no longer
be/is no longer supported» without risking being struck down.  It's a
somewhat separate discussion from the whole «what should be the default
init system» discussion, but it's one we (as a project) should be having
at some point.

-- 
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/m27g9vyux8@rahvafeir.err.no

Bug#727708: On diversity

[Ian Jackson]

Steve Langasek writes ("Bug#727708: On diversity"):
> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
> > I think (a) and (b) are pretty non-controversial. (c) and (d) are
> > required if we want to deal with new GNOME stuff and anything other
> > than systemd probably, and don't seem very hard to either do or
> > document. (e), (f) and (g) seem like a fairly straightforward of
> > allowing for multiple init systems in Debian. I think something like
> > (i) might be a good way of sunsetting tech ctte decisions so if
> > there's an actual consensus in future, there's no need to get a
> > pro-forma vote from the ctte to make changes in future. YMMV of
> > course.
> 
> For my part I think this is generally a good idea, but I have the impression
> that at least Russ would be strongly opposed to this because it's too
> prescriptive.  Probably not much sense in fleshing out such a reolution if
> there's not a consensus for it.

I lost track of all these (a)..(i).  But I wouldn't say that it's not
worth fleshing something out just because there's a lack of consensus.
The final resolution is not going to be a consensus decision anyway.

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/21213.2243.748614.454...@chiark.greenend.org.uk

Bug#727708: On diversity

[Anthony Towns]

On 20 January 2014 14:29, Russ Allbery  wrote:
> Steve Langasek  writes:
>> On Mon, Jan 20, 2014 at 01:17:13AM +1000, Anthony Towns wrote:
>> For my part I think this is generally a good idea, but I have the
>> impression that at least Russ would be strongly opposed to this because
>> it's too prescriptive.  Probably not much sense in fleshing out such a
>> resolution if there's not a consensus for it.
> I think this is all great work to do.  I'm just dubious about enforcing it
> with a technical committee decision.  This is the sort of thing that I was
> expecting to need to do on the Policy front once we have a decision.  I
> think that's the right forum for drilling into the details.

So I wondered what it might look like to say the same thing in a
minimally prescriptive way. Not even going to try guessing if this is
anywhere sufficient as far as Russ is concerned -- I'm not claiming to
know where Russ might draw the line on that topic. I've also added
some minimal tech ctte-esque boiler plate; I'm sure Ian could do
better.

---
The tech ctte determines as follows:

  [non-essential-init] In order to allow Debian users and developers
to easily design, test and deploy alternative init systems both now
and in the future, no init system in Debian should be provided via an
Essential:yes package.

  [default-init] Having examined the features and bugs of the various
init systems packaged for Debian, the default init system for jessie
for Linux architectures shall be {OpenRC | systemd | upstart |
determined by a GR}.

The tech ctte further offers the following advice to maintainers:

  [logind] The systemd/logind API provided by systemd and documented
on the freedesktop API will be important for a number of packages, and
that API should be made available within Debian for users of init
systems other than systemd. The various non-systemd init system
maintainers are encouraged to work with the systemd maintainers and
upstream to limit the code duplication that may result from this, and
to ensure enhancements and bug fixes are as widely available as
practical (both within Debian for different inits/architectures and
upstream). The maintainers involved should work through the policy
process to establish a virtual package for this API if needed.

  [required-init] In order to avoid users mistakenly removing all init
systems from their machine, we recommend the init maintainers
establish a virtual package (eg, "init-system") that all init systems
in Debian both provide and conflict with, and that an Essential:yes
package depend on that virtual package. This should be undertaken
using the normal policy process.

  [init-minimal-compatability] In order to make it simple for packages
to work with different available init systems, a simple means of
providing a startup script/configuration that is understood by all
Debian init systems should be documented in policy as a requirement
for for packages providing the init system virtual package. This may
be providing a sysvinit style script and adding it via update-rc.d for
instance. This method may be assumed to always be available if the
[required-init] advice is followed, and thus packages can avoid a
dependency on the virtual package.

  [init-crossgrades] In order to provide a good user experience when
switching init systems, maintainers of init systems other than the
default should test converting both to and from their init system, and
that the system is able to correctly shutdown and restart after
transitions to different init systems.

  [init-related-patches] Maintainers should accept non-intrusive
patches to provide enhanced support for init systems (both for the
default init and other inits included in Debian). Patches may be
considered intrusive by the maintainer if they introduce additional
dependencies or significant patches to code that are not accepted
upstream. Patches that merely add files to the package or provide
extra code to maintainer scripts should generally not be considered
intrusive. Where a reasonable amount of time has been given to the
maintainer to review proposed patches via the BTS, and no objection
has been raised, a NMU to incorporate the patch is appropriate.

  [cgroups] Maintainers should be aware cgroups is a Linux-only
feature; if their package requires the use of cgroups to be usable it
should be configured to not build for non-Linux architectures. Where
cgroups support is a compile-time feature, it should generally be
supported on Linux architectures, and disabled on non-Linux
architectures, for the same reason.

  [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus
should be aware that unless/until this changes, requiring use of a
systemd unit file for startup will likewise require their package to
be configured to not build for non-Linux architectures.
---

I think the [non-essential-init] and any of the four options for
[default-init] would 100% s

Bug#727708: On diversity

[Ian Jackson]

(Thorsten: your message went to debian-ctte@lists when it should have
gone to the bug report.  Can you try to make whatever cause that not
do that again please ?

Philipp: therefore, your message also went to the list directly and
not via the bug.)

Philipp Kern writes ("Re: Bug#727708: On diversity"):
> On 2014-01-21 19:04, Thorsten Glaser wrote:
> >>  [systemd-portability] Maintainers should be aware systemd relies
> >> heavily on cgroups and potentially other Linux-only features, and thus
> > This is also heavy on kernel configs, FWIW. But the question here
> > is: will maintainers please set the Architecture field of their
> > source packages *not* to “all” but only to those it’ll build/work
> > on?
> 
> They should not. If you require systemd at runtime, build-depend on it 
> and you will not be scheduled on other architectures. Of course we push 
> this more and more which makes accurate statistics of what's 
> legitimately excluded on an architecture to calculate coverage a bit 
> harder. But it is still possible, especially if we have highly visible 
> nodes like systemd in the graph.


--
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/21214.49493.817269.315...@chiark.greenend.org.uk

Bug#727708: On diversity

[Uoti Urpala]

On Thu, 2014-01-16 at 17:00 -0800, Russ Allbery wrote:
> Uoti Urpala  writes:
> > I think the divergence has gone too far in things like non-Linux ports.
> > They have had an overall negative effect on people working on Linux
> > within Debian and people creating derivatives.
> 
> I have to take exception to this.  There has been a great deal of
> *concern* from people over the past two years that the non-Linux ports
> *might* have a negative effect on Linux in the context of this particular
> discussion.

I consider the effect on the init system decision process so far to
already be an example of actual negative effects. Even if it does not
ultimately lead to an inferior system being chosen for Linux (which
would be a major harm), the portion of discussion that has been about
non-Linux ports has been completely out of proportion compared to their
potential benefit/importance, has made the decision process harder, and
has made it more difficult for anyone else to follow the discussion or
form an informed opinion based on it.

>   But, in the meantime, the non-Linux porters have been
> first-class Debian contributors over the years.  They have not
> substantially gotten in the way of Debian's processes, certainly no more
> than any Linux port to a more obscure architecture,

I don't have any numbers, but I would be surprised if that "no more
than" were true. The kernel and compiler already abstract away most of
hardware differences, and ignoring toolchain issues, I'd expect most of
hardware-specific failures to be things that could be considered general
bugs in the software even on platforms where it works. By comparison,
changes required by kernel differences are generally not positive on
other platforms.

>  and they have
> contributed a great many improvements to our software.
> 
> For example, I think special thanks should go to the Hurd porters for
> extended, thankless work on removing static buffers from the code in the
> archive.  They were doing so because some of the constants used to size
> those buffers are not portable to the Hurd, but using static buffers to
> store paths and related strings is often incorrect regardless of its
> portability, and can even be a security issue depending on how the code is
> written.  The Hurd porters have provided reasonable patches that can go
> back to upstream and result in objectively more robust software.  I have

Those are probably among the most useful patches, but I think they're
still very minor, and not worth the maintainer work adding distro-
specific patches in Debian (as opposed to letting it become part of
upstream code). Most changes will not be useful on other kernels.

There are also other costs. For example, kFreeBSD issues have prevented
testing migration of packages. Even if systemd is chosen as Linux init,
will everyone packaging daemons or other software interacting with init
for Debian be expected to remember guidelines or even do things
differently because of issues that only matter for non-Linux?

"zgrep -i kfreebsd /usr/share/doc/*/changelog.Debian.gz" shows over 1000
different matches just on this machine. Of course some of those packages
could be maintained by people who personally really wanted to work on
kFreeBSD regardless of its value, but I doubt the majority is. IMO
justifying that amount of work, and claiming that kFreeBSD has not had a
negative effect, requires showing some concrete benefit.


-- 
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/1390442078.4304.209.camel@glyph.nonexistent.invalid

Bug#727708: On diversity

[Russ Allbery]

Uoti Urpala  writes:

> I consider the effect on the init system decision process so far to
> already be an example of actual negative effects.

Fair enough.  You're certainly entitled to your opinion.  I don't agree
with you, and I think it's unlikely either of us are going to change each
other's mind, on this or on the other points you mention.

I would really appreciate it if you would stop reiterating your position
on non-Linux ports in this bug, though.  I think everyone who has read
either this mailing list or debian-devel is, at this point, well aware of
your position, and has heard all of your arguments.  Restating them just
provokes more argument, none of which has any possibility of changing
anyone's mind, and hence is simply noise from the perspective of this
discussion.

-- 
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/8738kfla80@windlord.stanford.edu

Bug#727708: On diversity

[Adrian Bunk]

On Wed, Jan 22, 2014 at 03:23:32AM +1000, Anthony Towns wrote:
>...
>   [non-essential-init] In order to allow Debian users and developers
> to easily design, test and deploy alternative init systems both now
> and in the future, no init system in Debian should be provided via an
> Essential:yes package.
>...
>   [init-crossgrades] In order to provide a good user experience when
> switching init systems, maintainers of init systems other than the
> default should test converting both to and from their init system, and
> that the system is able to correctly shutdown and restart after
> transitions to different init systems.
>...

IMHO in init-crossgrades the "init systems other than the default should"
has to be replaced with "all init systems have to".

Not being able to switch away from the default init system (that you are 
e.g. getting with a fresh installation) would completely undermine your 
goal of allowing users to easily switch init systems.

And "should" sounds too optional - if "switching init systems" is 
considered important, then that has to be a requirement for any
init system for being shipped in a release.

> Cheers,
> aj

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/20140125175220.ga23...@bunk.dyndns.info

Re: Bug#727708: On diversity

[Thorsten Glaser]

Anthony Towns dixit:

>  [default-init] Having examined the features and bugs of the various
>init systems packaged for Debian, the default init system for jessie
>for Linux architectures shall be {OpenRC | systemd | upstart |

Please do not forget sysv-rc here.

>determined by a GR}.

>  [systemd-portability] Maintainers should be aware systemd relies
>heavily on cgroups and potentially other Linux-only features, and thus

This is also heavy on kernel configs, FWIW. But the question here
is: will maintainers please set the Architecture field of their
source packages *not* to “all” but only to those it’ll build/work
on?

bye,
//mirabilos
-- 
 Warum ist MirWebseite eigentlich so cool?   weil ich
ich sie geschrieben habe   Hast du sie geschrieben oder geforkt?
 geschrieben, from scratch   Ach, deshalb finde ich
auch so selten Bugs dadrin. Irgendwie hast du Recht.


--
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.1401211801540.19...@herc.mirbsd.org

Re: Bug#727708: On diversity

[Philipp Kern]

On 2014-01-21 19:04, Thorsten Glaser wrote:

 [systemd-portability] Maintainers should be aware systemd relies
heavily on cgroups and potentially other Linux-only features, and thus

This is also heavy on kernel configs, FWIW. But the question here
is: will maintainers please set the Architecture field of their
source packages *not* to “all” but only to those it’ll build/work
on?


They should not. If you require systemd at runtime, build-depend on it 
and you will not be scheduled on other architectures. Of course we push 
this more and more which makes accurate statistics of what's 
legitimately excluded on an architecture to calculate coverage a bit 
harder. But it is still possible, especially if we have highly visible 
nodes like systemd in the graph.


Kind regards
Philipp Kern


--
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/ae3cfbafe25945c821dc06b7d1e44...@hub.kern.lc

Re: Bug#727708: On diversity

[Steve Langasek]

On Mon, Jan 20, 2014 at 08:27:47AM +0100, Tollef Fog Heen wrote:
> > GNOME certainly uses these interfaces already.  Whether they should be
> > considered a "dependency" or not is probably something that should be left
> > to the maintainers' discretion.  But I think they should certainly be
> > handled the same way as logind, generally - with a dependency on some
> > virtual package that other implementations could provide (or that can be
> > provided by a binary package from systemd source that doesn't depend on pid
> > 1 - since these dbus services all work fine on non-systemd systems, and
> > there's no technical reason that should ever change given the function of
> > the services in question).

> I'm willing to look at adding virtual packages for those once we
> actually see alternative implementations happening.  Adding them because
> somebody might, maybe, possibly add them somewhere down the line sounds
> premature.

Well, I don't agree that it's premature at all.  We're talking about very
distinct sets of interfaces being exposed (dbus services vs.  init system
interfaces), and conflating them under a single package name (...and
upstream project name) is IMHO the root of all the upset around GNOME and
systemd at the moment.

Providing these virtual packages may seem frivolous while there's only a
single implementor, but it makes it very clear to all developers that the
systemd and GNOME maintainers have done their part to accomodate
alternatives... and that if alternative implementations do not emerge,
people who are unhappy with this have no one but themselves to blame.  In
that sense, I think it's a useful technique for forestalling future
flamewars, even if it's *technically* easy to make this change at some
future point.

> As for whether they should work with non-pid1 or not, it's also a
> question about what we (the systemd maintainers) want to support.  The
> daemons currently don't require systemd as pid1, but given all the flak
> over maybe making logind require systemd as pid1 there is a very strong
> incentive to not make those implementations work with another init.  The
> CTTE here and in the past (see NM) views regressions as much more
> serious than lacking implementations.

> I think this is pretty sad and gives maintainers perverse incentives,
> since there's not really any graceful way to say «this will no longer
> be/is no longer supported» without risking being struck down.  It's a
> somewhat separate discussion from the whole «what should be the default
> init system» discussion, but it's one we (as a project) should be having
> at some point.

Speaking for myself, I don't think it's the systemd maintainers'
responsibility to make logind work on non-systemd systems, but that it is
your responsibility to communicate with the project (or maintainers of
related packages such as systemd-shim) about upcoming changes that would
introduce regressions and make a reasonable effort to coordinate updates so
that the maintainers of those related packages have an opportunity to
respond.

For instance: to date we've discussed the bump to v205 in Debian in rather
fuzzy terms.  Is there a specific deadline by which you think this needs to
be taken into Debian (either to ensure it's stabilized for the jessie
release, or in response to requirements from reverse dependencies)?  Work on
cgmanager+systemd-shim is progressing, but it would be best to know when it
needs to be available in Debian in order to unblock you for systemd v205.

-- 
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

Re: Bug#727708: On diversity

[Tollef Fog Heen]

]] Steve Langasek 

> On Mon, Jan 20, 2014 at 08:27:47AM +0100, Tollef Fog Heen wrote:
> > > GNOME certainly uses these interfaces already.  Whether they should be
> > > considered a "dependency" or not is probably something that should be left
> > > to the maintainers' discretion.  But I think they should certainly be
> > > handled the same way as logind, generally - with a dependency on some
> > > virtual package that other implementations could provide (or that can be
> > > provided by a binary package from systemd source that doesn't depend on 
> > > pid
> > > 1 - since these dbus services all work fine on non-systemd systems, and
> > > there's no technical reason that should ever change given the function of
> > > the services in question).
> 
> > I'm willing to look at adding virtual packages for those once we
> > actually see alternative implementations happening.  Adding them because
> > somebody might, maybe, possibly add them somewhere down the line sounds
> > premature.
> 
> Well, I don't agree that it's premature at all.  We're talking about very
> distinct sets of interfaces being exposed (dbus services vs.  init system
> interfaces), and conflating them under a single package name (...and
> upstream project name) is IMHO the root of all the upset around GNOME and
> systemd at the moment.

I don't think we'd have any less upset if systemd had had a Provides:
logind in the control file.

> Providing these virtual packages may seem frivolous while there's only a
> single implementor, but it makes it very clear to all developers that the
> systemd and GNOME maintainers have done their part to accomodate
> alternatives... and that if alternative implementations do not emerge,
> people who are unhappy with this have no one but themselves to blame.  In
> that sense, I think it's a useful technique for forestalling future
> flamewars, even if it's *technically* easy to make this change at some
> future point.
> 
> > As for whether they should work with non-pid1 or not, it's also a
> > question about what we (the systemd maintainers) want to support.  The
> > daemons currently don't require systemd as pid1, but given all the flak
> > over maybe making logind require systemd as pid1 there is a very strong
> > incentive to not make those implementations work with another init.  The
> > CTTE here and in the past (see NM) views regressions as much more
> > serious than lacking implementations.
> 
> > I think this is pretty sad and gives maintainers perverse incentives,
> > since there's not really any graceful way to say «this will no longer
> > be/is no longer supported» without risking being struck down.  It's a
> > somewhat separate discussion from the whole «what should be the default
> > init system» discussion, but it's one we (as a project) should be having
> > at some point.
> 
> Speaking for myself, I don't think it's the systemd maintainers'
> responsibility to make logind work on non-systemd systems, but that it is
> your responsibility to communicate with the project (or maintainers of
> related packages such as systemd-shim) about upcoming changes that would
> introduce regressions and make a reasonable effort to coordinate updates so
> that the maintainers of those related packages have an opportunity to
> respond.

I'm not convinced that any maintainer might insert themselves into a
dependency chain (as systemd-shim does) and expect to be accomodated in
all cases.  Sometimes, sure, but it all depends on context and
circumstances.

> For instance: to date we've discussed the bump to v205 in Debian in rather
> fuzzy terms.  Is there a specific deadline by which you think this needs to
> be taken into Debian (either to ensure it's stabilized for the jessie
> release, or in response to requirements from reverse dependencies)?  Work on
> cgmanager+systemd-shim is progressing, but it would be best to know when it
> needs to be available in Debian in order to unblock you for systemd v205.

I don't have a specific date in mind, no.  Having 209 (once it's out) in
jessie also depends on when we have a kdbus enabled kernel.  That said,
due to other commitments, I'm unlikely to have time to do much with
systemd in February, but say having an updated package in by Easter
would be a worthwhile goal, I think.

-- 
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/8738k2mmts@xoog.err.no