Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Zbigniew Jędrzejewski-Szmek]

On Tue, Nov 04, 2014 at 01:38:24AM +, Jonathan de Boyne Pollard wrote:
> Zbigniew Jędrzejewski-Szmek:
> >Distribution packages have been  almost all converted to systemd
> > services, with a handful of less-used-packages remaining [1].
> 
> Jóhann B Guðmundsson, the erstwhile feature owner for Fedora's
> System 5 rc to systemd units conversion project, states that the
> conversion is about four fifths done.
Yeah, it seems that my query was overly simplistic. On the one hand,
I didn't catch all the initscripts, on the other hand, I didn't filter
out packages which have have a systmed unit but still carry the init
script. Sorry for that, I should have checked more carefully.
It seems that there's 100-200 unconverted packages.

Zbyszek


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141104030109.gb23...@in.waw.pl

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jonathan de Boyne Pollard]

Zbigniew Jędrzejewski-Szmek:

Distribution packages have been  almost all converted to systemd

> services, with a handful of less-used-packages remaining [1].

Jóhann B Guðmundsson, the erstwhile feature owner for Fedora's System 5 
rc to systemd units conversion project, states that the conversion is 
about four fifths done.


* http://lwn.net/Articles/617925/
* http://fedoraproject.org/wiki/Features/SysVtoSystemd


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54582e10.9020...@ntlworld.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

Josh Triplett  writes:
> Russ Allbery wrote:

>> There are a ton, but because Debian architectures encode choice of
>> kernel, they're represented in the archive as packages that are not
>> available for kFreeBSD or Hurd, or only available for kFreeBSD, or only
>> available for Hurd.

> That said, dependencies on specific kernel versions or features have no
> representation at all in Debian package metadata, which proves rather
> painful to deal with in packages that need specific kernel features
> enabled in order to function.

True, and *that* is for the same reason why representing the running init
system in package metadata is hard.  It's not normally useful to depend on
a particular version of the Linux kernel, since all that does is ensure
that the kernel is installed, not that the system is currently booted
under it (which is the part that actually matters for nearly all
software).

I can't think of a good way to do this that doesn't make the situation
even more confusing for the user, but if someone else can, that would be a
useful thing to have fixed in several different ways.  Which I guess is
Wanderer's point, so maybe I've come around to agreeing with that part of
it.  :)

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87bnop3ry1@hope.eyrie.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

The Wanderer  writes:
> On 11/02/2014 at 07:58 PM, Russ Allbery wrote:

>> That's because the point of systemd-shim is to provide the services
>> that logind requires without running systemd as PID 1, so that packages
>> can then depend on logind without requiring systemd be PID 1.  That
>> didn't require a direct dependency on systemd because that dependency
>> comes in via libpam-systemd or some other route in the software using
>> logind.

>> In other words, the whole point of systemd-shim is to enable the use of
>> logind.  It's not replacing it with something else.

> ...I'm confused.

> Assuming you're correct in your description of the purpose of
> systemd-shim (I could argue that the concept of the package could /
> should extend to providing "stub" implementations of the interfaces
> provided by the various services provided by systemd-the-project), then
> it seems obvious that systemd-shim must necessarily depend on having
> systemd-the-package installed, since otherwise logind itself would not
> be installed.

> However, you've presented this as an explanation of the fact that
> systemd-shim does not list a "Depends: systemd" - when in fact it would
> seem to require that systemd-shim *must* list such a dependency.

Yeah, I was confusing, sorry.

The dependency direction is the other way around.  systemd-shim doesn't
depend on logind; logind depends on systemd-shim (in the absence of
systemd as PID 1).

So you're right that in theory you could use systemd-shim to enable the
use of other software that would otherwise want systemd as PID 1.
However, in practice what it's used for is allowing use of logind without
systemd.  Look at libpam-systemd, which is the key package for the
dependency structure since libpam-systemd being installed (and enabled)
effectively means logind is available.  libpam-systemd depends on systemd,
*and* on either systemd-sysv (systemd as PID 1) *or* on systemd-shim.

> This comes after I pointed out that the package does not list such a
> dependency, which comes after you (as far as I can tell) claimed that it
> had always listed such a dependency,

Well, what I said was that systemd-shim requires systemd, not that it
lists it as a dependency.  You're right that that's a confusing way of
putting it.

What I meant was that the normal use case of systemd-shim requires that
logind be installed, and hence also requires the systemd package.  In
other words, using systemd-shim for DEs doesn't avoid requiring logind.
It just provides another way of using logind.

The only point that I was trying to make is that systemd-shim is not
really an alternative to systemd.  It does provide a different
implementation of one feature (cgroups management) via cgmanager, but in
general you're still going to want systemd components installed, and
indeed the original goal of systemd-shim was to make that possible.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87h9yh3s2z@hope.eyrie.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[The Wanderer]

(Responding quickly to only the part I think I can address well on short
notice, without needing to spend a long time thinking it over.)

On 11/02/2014 at 07:58 PM, Russ Allbery wrote:

> The Wanderer  writes:

>> systemd-shim 8.2 and 7.1 do not list a dependency on systemd, or
>> appear to invoke one indirectly; as far as I recall, no such
>> dependency had previously been present, either. Attempting to
>> install systemd-shim and remove systemd in a --dry-run does not
>> complain.
> 
> That's because the point of systemd-shim is to provide the services
> that logind requires without running systemd as PID 1, so that
> packages can then depend on logind without requiring systemd be PID
> 1.  That didn't require a direct dependency on systemd because that
> dependency comes in via libpam-systemd or some other route in the
> software using logind.
> 
> In other words, the whole point of systemd-shim is to enable the use
> of logind.  It's not replacing it with something else.

...I'm confused.

Assuming you're correct in your description of the purpose of
systemd-shim (I could argue that the concept of the package could /
should extend to providing "stub" implementations of the interfaces
provided by the various services provided by systemd-the-project), then
it seems obvious that systemd-shim must necessarily depend on having
systemd-the-package installed, since otherwise logind itself would not
be installed.

However, you've presented this as an explanation of the fact that
systemd-shim does not list a "Depends: systemd" - when in fact it would
seem to require that systemd-shim *must* list such a dependency.

This comes after I pointed out that the package does not list such a
dependency, which comes after you (as far as I can tell) claimed that it
had always listed such a dependency, which comes after I mentioned that
the discussion in bug 765101 seemed to indicate that such an (explicit)
dependency would be added.

Leaving aside the unnecessarily confusing nomenclature which no one
seems interested in trying to clear up even for colloquial use, I can't
make any sense out of this. Could you try to explain it more clearly?
(Not necessarily on-(this-)list, unless you think others might be
interested. I'm on -user, -devel, -project, -policy, and -mentors, as
well as here.)

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Josh Triplett]

[I agree wholeheartedly with Russ's points regarding systemd and logind.
One tangential response to a different point:]

Russ Allbery wrote:
> There are a ton, but because Debian architectures encode choice of kernel,
> they're represented in the archive as packages that are not available for
> kFreeBSD or Hurd, or only available for kFreeBSD, or only available for
> Hurd.

That said, dependencies on specific kernel versions or features have no
representation at all in Debian package metadata, which proves rather
painful to deal with in packages that need specific kernel features
enabled in order to function.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141103024643.GA20402@thin

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

The Wanderer  writes:

> Is it? I thought part of the problem is that there are packages whose
> upstream supports (or at least enables) compiling with / without
> integration to functionality provided by systemd, and which are provided
> in Debian only as compiled with that functionality enabled, with no
> alternative package which omits that functionality. I had the impression
> that GNOME was one such (set of) package(s).

See Josselin's reply on this.  You in theory can build GNOME with
ConsoleKit support, but in terms of getting a generally working experience
for the user, it's probably less work to get systemd-shim working with
logind than to bring the ConsoleKit code up to snuff and support it.
(Although apparently someone is trying the latter, so maybe this will
change.)  Either way, this isn't a simple matter of the package
maintainers switching some flags, so adding more packaging tools doesn't
really help.

In other words, I think you're trying to solve the wrong problem.  The
problem you're trying to solve is not the obstacle that's getting in the
way of good support for multiple init systems.

> How does software which requires the features of a particular kernel
> currently depend on having that particular kernel active? I would have
> expected it to be via a dependency on 'linux-image' or 'kfreebsd-image'
> or the like, but at a glance I don't see my current linux-image-*
> package providing any such virtual package, and offhand I don't know of
> any kernel-dependent packages except for systemd - which does not
> obviously appear to express any kernel-related dependency.

There are a ton, but because Debian architectures encode choice of kernel,
they're represented in the archive as packages that are not available for
kFreeBSD or Hurd, or only available for kFreeBSD, or only available for
Hurd.  A better example to look at if you want to see the problem handled
via dependencies would be how Kerberos packages in the archive are
handled, where basically everything is built with MIT except for a small
number of packages linked with Heimdal.  Or at the situation with OpenSSL
and GnuTLS.

> I thought I'd adequately allowed for both sides of that? The "software
> that has been ported" would fall under "can be packaged so as to be
> compiled with / without support", and the "software that has not been
> ported" would fall under "can be packaged so as for the package to be
> available when the functionality is and not when the functionality is
> not". Is that not enough?

Yeah, I had missed the second part, sorry.

I think this is part of the question about how to handle installing a leaf
package that only works with systemd.  Ideally, if people have the time
and energy to keep maintaining things like systemd-shim, we avoid this
problem.  It's rather surprising to have the init system changed by
installing a package, but it's also surprising to have the package not
appear available in apt until you reboot into a different init system
(which I think is what you're proposing).  That doesn't really make sense
to me.  What we may end up with is having packages be installable but not
actually work, which is another less-than-ideal approach, but which I'm
pretty sure we currently do with various other things in the archive with
similar requirements that are hard to represent with dependencies.

> udev and possibly the MTA is a point, but if you can only have one libc
> installed at a time, that's news to me. Certainly any given program can
> link with only one, and some programs may not work with some libc
> implementations, but I wouldn't have intuitively expected having a
> second libc installed separately (and linked against by whatever you
> want to compile against it) would be a problem...

You can install a second libc, but nothing uses it, and you can't load any
shared libraries in programs built against it without rebuilding all of
those shared libraries.  So, effectively, you can install it but you can't
use it for anything other than completely isolated development, at which
point you may as well just use a chroot.  I think it's fair to say that
you can only have one libc.

> As to the compiler, I either have to disagree with you, or misunderstand
> what you're talking about. It's certainly possible to have multiple
> compilers installed and functional side-by-side on a single machine, you
> just can't have more than one of them set as 'cc' or the equivalent -
> which is just a matter of the per-invocation default, really, rather
> than a system-wide exclusive configuration. That even seems to be mostly
> supported, at least as far as multiple versions of gcc.

I was talking more broadly about places where Debian picks just one of
something.  I see you were talking specifically about what can be
installed on a single system; in that case, yes, you can easily install
multiple compilers.  You can also easily install multiple init systems,
but the system can only be booted with one of them at a tim

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Olav Vitters]

On Fri, Oct 31, 2014 at 06:07:20PM +0900, Tristan Van Berkom wrote:
> Is systemd the problem or is the GNOME Desktop Environment[0] ?

Could you maybe address this within GNOME first instead of on Debian?
Going to Debian because you have a concern within GNOME seems rather
counter productive. First raise it within GNOME, not use Debian to raise
things.

>   o The GNOME Desktop needs D-Bus interfaces to bring event based
> notifications to the Desktop Environment.

You're skipping the entire bit where logind does something with ttys.
Functionality that is used for Wayland. In any case, this could all be
so much easier if there was actual communication going on.

Deciding something via a GR is a one off shot.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141031110806.ga28...@bkor.dhs.org

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Andrey Rahmatullin]

On Thu, Oct 30, 2014 at 11:02:22PM +0100, Svante Signell wrote:
> I should not have mentioned any company at` all, sorry :(
That would be the first step, yes.

-- 
WBR, wRAR


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141031090450.ga19...@belkar.wrar.name

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Tristan Van Berkom]

On Fri, 2014-10-31 at 09:37 +0530, Rustom Mody wrote:
> On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> > [Disclaimer: I am not a debian developer myself and probably do not have
> >  the right to vote here, I am however a long time contributor and
> >  maintainer in GNOME who has been watching this thread and I feel I have
> >  a responsibility to add to this conversation ]
[snip]

> 1. If the anti-systemd's brigade is really phobic and are not being
>reasonable enough about "I dont want systemd anywhere near my system"
>why not rename libraries like systemd-shim, libsystemd0 etc to not have the
>phobia-inducing word?

I don't believe it's phobia, there are plenty of reasons, when
developing some embedded/single purpose product and using a reliable
upstream debian as your base, to choose the more tried and trusted
option, but let's not get into that (it's been done to death, and I
don't feel I'm contributing anything of additional value to this
conversation by going down that road).

> 2. Is systemd the problem or is gnome the problem?
> 
>On Mon, 20 Oct 2014 Charles Plessy wrote:
>> Regarding what is proposed, it is actually unclear.  The consequence
>> of accepting the main proposal may range anywhere between “do nothing
>> special” and “harrass the GNOME and systemd maintainers until they
>> quit”.  I am sure that this is not Ian's goal, but I am not sure he is
>> in position to prevent this to happen.
> 

I know I'm walking into a snake pit here but sure, I'll bite.

Is systemd the problem or is the GNOME Desktop Environment[0] ?

In my point of view the two now go hand in hand, they are both a valid
step into the future, however I don't feel that due diligence has been
taken for this technology's wide spread adoption.

The thing to understand here is that free software is generally slow in
terms of progress and excellent in terms of reliability, compatibility
and interoperability. This is the net result of having many entities
participate in software development in the open. Everyone has their own
valid requirements, so making sure software is developed properly in the
bazaar is much slower (and costlier) than it is in the cathedral, where
only one supporting entity's opinion matters.

So objectively speaking, what could have been done better ?

  o The GNOME Desktop needs D-Bus interfaces to bring event based
notifications to the Desktop Environment.

Instead of implementing a hurdle of platform specific code which
manages to receive system specific events (with varying success),
this D-Bus abstraction really is an improvement, this is the
direction we should all be taking, we should be doing that together.

But are these D-Bus APIs stable (yet) ?

  o systemd is currently the source of all of these D-Bus events which
the GNOME Desktop requires.

So systemd as an init system is possibly a nice young and upcoming
init system, but now portends to be more than just that, with all of
these extra services which replace components that we've already
grown to trust.

Did the GNOME/systemd maintainers propose patches to the already
existing and trusted daemons to issue these D-Bus events ?

Are there existing patches against udevd for instance, which allow
udevd to provide the D-Bus events which GNOME requires for a good
user experience ? (for a random example)

I think the answer to the above questions are currently 'no', which
means that the new GNOME Desktop was able to be developed much faster
than it would have been had they been playing fair and cooperating with
the wider FOSS community (which would require waiting on maintainers of
already trusted system components to accept, at least soft dependencies
on D-Bus and patches to produce the D-Bus events we require).

Again, I should reiterate that the approach RedHat has taken with GNOME
is a valid one, a lot of progress has been made quickly, and what has
evolved from that is a proof of concept/reference implementation which I
hope will be standardized appropriately and adopted by the wider FOSS
community.

I don't think it's time to call this reference implementation stable, I
don't think that that would be a healthy decision for GNOME or for the
wider FOSS community.

As I mentioned in my initial mail, if one entity wants to foot the bill
for a development project as huge as this, we should not blame them for
not going the extra mile to meet the (heavy) expectations which are
appropriate in FOSS, however I also don't expect it to be considered
stable by other distributions so quickly, I would expect an incubation
period of 2-5 years or so while the D-Bus APIs in question stablize and
can be adopted by other Desktop implementations and other hardware
abstractions.

>suggests that keeping the gnome-devs happy takes precedence over
>other concerns
> 
>My impression is that when gnome went from 2 to 3 a large population
>of d

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

Russ Allbery  writes:

> Every time I look at that web page, I find another egregious error.
> This time, I just noticed that their minimal PID 1 implementation that
> they think is the be-all and end-all of PID 1 ends with a call to
> execve.  I'm going to be laughing about that for the rest of the night.

Ack, sorry, never mind this.  This was totally my mistake; I missed the
fork() in the middle of the if statement this time when I read it through.
Teaches me to reach too fast for a snarky comment.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87lhnwx0ql@hope.eyrie.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

Svante Signell  writes:

> PID 1 should be as small as possible, see a proposed implementation in:
> http://ewontfix.com/14/

That web page still cracks me up.  Not only does the author have no idea
how systemd works and makes multiple claims that are simply false, they
have no idea how *sysvinit* works.  You also have to love people who claim
to be authorities on how other people should write code and then proceed
to try to prove it with a model implementation that do no error checking
whatsoever.

Every time I look at that web page, I find another egregious error.  This
time, I just noticed that their minimal PID 1 implementation that they
think is the be-all and end-all of PID 1 ends with a call to execve.  I'm
going to be laughing about that for the rest of the night.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94cyive@hope.eyrie.org

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Rustom Mody]

On Thu, 30 Oct 2014 16:54:33 +0900 Tristan van Berkom wrote:
> [Disclaimer: I am not a debian developer myself and probably do not have
>  the right to vote here, I am however a long time contributor and
>  maintainer in GNOME who has been watching this thread and I feel I have
>  a responsibility to add to this conversation ]
>
> On Wed, 2014-10-29 at 16:41 -0500, Nikolaus Rath wrote:
> > Ian Jackson  writes:
> > > In the battle between those upstreams and Debian contributors who want
> > > everyone to use systemd, and those developers and users who don't want
> > > to use systemd, _someone_ is going to experience duress.
> >
> > I don't think that there are developers and users who want everyone to
> > use systemd (trolls excluded). There are just users and developers who
> > do not want to do the extra work that would be required to keep their
> > systems working without systemd, because that work should really be done
> > by the users and developers who don't want to use systemd.
>
> I think you've touched on the matter on which I have an opinion
> elegantly and directly right here. And I agree with what you say for the
> most part, except for the part where users and developers who do not
> want to use systemd should be going out of their way to implement
> alternatives for GNOME to run without systemd, this does not reflect the
> high standard of quality we've come to expect in general from FOSS
> communities.
>
> So what is the situation we have on the GNOME side ? From my perspective
> it's simple, we have highly skilled professionals working on two
> separate projects, the gnome-shell and systemd, let's not get personal,
> someone has to foot the bill for all the work here right ?
>
> So if RedHat wanted to invest in their new vision of the Desktop
> Environment, they should not have to pay for the extra work it should
> take for those projects to be embraced by the larger FOSS community, and
> that's completely fine and their prerogative, in any case, they have
> their means of distribution (rpms, fedora, etc).
>
> However, I do fear for the direction that GNOME in general is taking,
> I am personally invested in GNOME and I believe that we need to hold
> ourselves to a higher standard of quality than the "GNOME and nothing
> else" attitude that seems to have evolved in the name of progress.
>
> So while I cannot blame those who are funding this largely experimental
> leap into the future for drawing the line somewhere in their budget, I
> do expect long time stable distributions such as Debian to draw the line
> as to what they accept as stable. If the developers of gnome-shell and
> systemd want to participate in the larger FOSS community and have a
> venue in Debian, they should certainly be the ones doing the work to
> ensure the system meets some minimal expectations of interoperability.
>
> I am afraid that by making systemd (a project in it's relative infancy
> performing critical OS tasks), the default init system in Debian just
> because the maintainers of gnome-shell/gdm can't be bothered to operate
> on anything else, you (the Debian community) are sending a dangerous
> message that it's just fine for said GNOME maintainers to lower their
> standards of excellence. I fear that with this message things will not
> be improving.
>
> Yes, my motivations are self-centered, I think that the quality of the
> software produced in GNOME is at risk when external projects who use
> GNOME start to tolerate a nonchalant attitude towards stability and
> interoperability.
>
> For these reasons, I would (if I could) cast a vote in favor of Ian's
> GR, because I feel that GNOME should be doing better and I am afraid
> that there will be an increased lack of motivation to do so if the GR
> does not pass.
>
> Best Regards,
> -Tristan

Thank you very much Tristan for writing that mail.

Ive been a Unix user for 30 years and happy debian user for 15

And so seeing the fracas around systemd has been alarming.

Not that I have any data/opinion whether systemd is good/bad.
[I'm typing this from a systemd-ed jessie machine]

What alarms me is the combo of
- violent vitriol issuing from the anti-systemd camp
- The couldn't-care-less resultant-vector of the official-DD's response

[So also thanks Ian for the GR]

I would reiterate: I have no position (not enough knowledge really)
on systemd.

There is this well known story chicken-leg phobia.
[For those who dont know...]
Woman had a morbid phobia of chicken legs.
Was once invited to a party.
She made her usual check by phoning the hostess to confirm there were no
chicken legs. Hostess thoughtlessly said Ok.
But there was chicken... and legs!
The phobic's reaction was so violent that both she and the hostess had to
be taken to emergency room!


1. If the anti-systemd's brigade is really phobic and are not being
   reasonable enough about "I dont want systemd anywhere near my system"
   why not rename libraries like systemd-shim, libsystemd0 etc to not have th

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Matthias Urlichs]

Hi,

Svante Signell:
> 
> Why do you cut out the most important part of that message? You all
> trigged on the first part, I should not have mentioned any company at
> all, sorry :(
> 
Oh well, if you insist:

>>> The more important that Debian does not drop support for sysvinit then,
>>> until alternatives have stabilized :) (and systemd/uselessd is deferred
>>> to PID 2). PID 1 should be as small as possible, see a proposed
>>> implementation in: http://ewontfix.com/14/

The first sentence is a non-sequitur. We're not the ones who drop support
for sysvinit, Upstream does that. For the moment we're working on things
like systemd-shim to mitigate that decision. What else do you want us to
do instead, keep old versions of Gnome (and its dependencies, like
ConsoleKit :-/ ) (and KDE and whatever else) around and working? not likely.

The second sentence expresses your personal opinion without arguing in
its favor. IMHO http://ewontfix.com/14/ is misguided if not wrong; the
"implementation" will not support a couple of use cases that happen to be
important for some of us. Like restarting init after you upgrade your libc,
or cleanly shutting down your system, or starting an emergency shell if
/etc/rc fails to run for whatever reason.

Yeah, if systemd ever dies you get an automatic kernel restart. So? If your
PID2 fails under this implementation, you get a hung system with no way to
reboot it. Which is worse.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141031031930.ge3...@smurf.noris.de

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Zbigniew Jędrzejewski-Szmek]

On Thu, Oct 30, 2014 at 01:24:55PM -0500, Jordan Metzmeier wrote:
> On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard  wrote:
> >
> > That does not sound to me as Fedora _only_ supporting systemd, or am I
> > missing something?
> >
> 
> It looks like Fedora 20 still has a sysvinit package, but it won't
> exist in the next release[1]. Upstart is also retired[2]. I would
> consider the lack of available alternatives in their repo to be "only
> supporting systemd".
Fedora supports and will support sysvinit scripts. This does not
mean that you can run sysvinit to start the system, but only that
those scripts will be executed by systemd.

This is necessary for backwards compatibility and compatibility with
3rd party packages. Distribution packages have been almost all converted
to systemd services, with a handful of less-used-packages remaining [1].

So yes, for all intents and purposes, Fedora only supports systemd
(as PID 1).

Zbyszek

[1] $ repoquery -f '/etc/init.d/*'
dircproxy-0:1.2.0-0.22.RC1.fc22.x86_64
snake-server-0:0.11.1-5.fc21.noarch
ltsp-server-0:5.4.5-8.fc21.x86_64
conmux-0:0.0-22.493svn.fc22.noarch
gofer-0:0.77.1-2.fc21.noarch
powerman-0:2.3.5-9.fc22.i686
spawn-fcgi-0:1.6.3-8.fc22.x86_64
powerman-0:2.3.5-9.fc22.x86_64
ldirectord-0:3.9.5-12.fc22.2.x86_64
svxlink-server-1:0.13.1-14.fc22.x86_64
python-carbon-0:0.9.12-4.fc21.noarch
ltsp-client-0:5.4.5-8.fc21.x86_64
ratbox-services-0:1.2.1-11.fc21.x86_64
cyphesis-0:0.6.2-3.fc22.x86_64
sslogger-slogd-0:0.96-13.fc22.x86_64
vhostmd-0:0.5-9.fc22.x86_64


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030215103.gp2...@in.waw.pl

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Svante Signell]

> Svante Signell:
> > 
> > > And OpenSUSE also dropped support:
> > 
> > Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> > derived. Can anybody guess where systemd is developed?
> > 
> Well, OpenSUSE (and several others who have by now switched to systemd)
> are not. So?

Why do you cut out the most important part of that message? You all
trigged on the first part, I should not have mentioned any company at
all, sorry :(

> The more important that Debian does not drop support for sysvinit then,
> until alternatives have stabilized :) (and systemd/uselessd is deferred
> to PID 2). PID 1 should be as small as possible, see a proposed
> implementation in: http://ewontfix.com/14/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414706542.4406.1.ca...@gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jordan Metzmeier]

On Thu, Oct 30, 2014 at 12:32 PM, Jonas Smedegaard  wrote:
>
> That does not sound to me as Fedora _only_ supporting systemd, or am I
> missing something?
>

It looks like Fedora 20 still has a sysvinit package, but it won't
exist in the next release[1]. Upstart is also retired[2]. I would
consider the lack of available alternatives in their repo to be "only
supporting systemd".

[1] http://pkgs.fedoraproject.org/cgit/sysvinit.git/tree/
[2] https://admin.fedoraproject.org/pkgdb/package/upstart/


Regards,
Jordan Metzmeier


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cad758rismaeciomirks6jerfs6ormbq0myurcen3s0unnwy...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jonas Smedegaard]

Quoting Josh Triplett (2014-10-30 15:04:04)
> Aigars Mahinovs wrote:
>> Fedora actually is not that decisive, as far as I read here -
>> https://fedorahosted.org/fpc/ticket/243
>
> That ticket turned down the suggested policy of "packages MUST NOT 
> support sysvinit".  That doesn't mean "packages MUST support 
> sysvinit", or "packages MUST NOT depend on systemd".
>
> The Fedora policy: "Packages may also provide a SysV initscript file,
> but are not required to do so."

That does not sound to me as Fedora _only_ supporting systemd, or am I 
missing something?

As a reminder, here's what I believe we are talking about here:

Quoting Aigars Mahinovs (2014-10-30 11:06:47)
> Have other distros switched to _only_ supporting systemd? Changing the 
> default is not the same.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Matthias Urlichs]

Hi,

Svante Signell:
> 
> > And OpenSUSE also dropped support:
> 
> Of course RHEL and Fedora dropped sysvinit support, they are Redhat
> derived. Can anybody guess where systemd is devloped?
> 
Well, OpenSUSE (and several others who have by now switched to systemd)
are not. So?

Please stop the corporate bashing. Yes, RH employs people who work on
systemd. That does NOT by itself imply that they're trying to push an
inferior, locked-in, or _whatever_ solution down our collective throats.

Companies behave rationally (assuming that 'my first priority is making
money' is rational, but that's a different topic).

The corollary is: if transitioning to systemd would waste everybody's time
and effort, RH wouldn't do it. For the very simple reason that the faster
RH's sysadmins can solve their customers' problems, the more money they make.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030162418.gd3...@smurf.noris.de

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Paul Wise]

On Thu, Oct 30, 2014 at 11:12 PM, Svante Signell wrote:

> Can anybody guess where systemd is devloped?

No need to guess when they have git logs:

http://cgit.freedesktop.org/systemd/systemd/log/

I recognise people from these distros in the git logs: debian mageia
redhat archlinux ubuntu tizen suse gentoo coreos mandriva slackware
jolla exherbo fedora.

The count of commit authors by domain is:

$ git log | grep Author | sort -u | grep -o @.* | tr -d '@>' | sort |
uniq -c | sort -nr | head
146 gmail.com
 45 redhat.com
 12 suse.de
 12 gentoo.org
 12 canonical.com
  8 intel.com
  8 googlemail.com
  7 samsung.com
  7 debian.org
  6 linux.intel.com
...

-- 
bye,
pabs

https://wiki.debian.org/PaulWise


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caktje6egxu9g2wbkkpk5z+ayjrhjd4-gmy1uiazdpxa2dng...@mail.gmail.com

Re: Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Svante Signell]

> > 
> > ArchLinux is clearly dropping sysvinit. RHEL documentation also seems
> > to imply that Sysvinit and Upstart are both dropped in 7+.
> > 
> > Fedora actually is not that decisive, as far as I read here -
> > https://fedorahosted.org/fpc/ticket/243
> 
> It wasn't 19 months ago, but is petty decisive now:
> 
> https://fedorahosted.org/fpc/ticket/359
> http://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files
> 
> And OpenSUSE also dropped support:
> 
> https://www.suse.com/releasenotes/x86_64/openSUSE/12.3/#sec.123.sysv

Of course RHEL and Fedora dropped sysvinit support, they are Redhat
derived. Can anybody guess where systemd is devloped?

The more important that Debian does not drop support for sysvinit then,
until alternatives have stabilized :) (and systemd/uselessd is deferred
to PID 2). PID 1 should be as small as possible, see a proposed
implementation in: http://ewontfix.com/14/


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414681924.15088.222.ca...@g3620.my.own.domain

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jonathan Dowland]

On Thu, Oct 30, 2014 at 09:46:44AM +, Adam D. Barratt wrote:
> fwiw, as this seems to be a commonish error - you mean "could not
> care less". People who could care less by definition do care.

It's an en_US thing, I think.

http://public.wsu.edu/~brians/errors/couldcare.html


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030143002.ga14...@chew.redmars.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jeroen Dekkers]

At Thu, 30 Oct 2014 14:32:29 +0200,
Aigars Mahinovs wrote:
> 
> On 30 October 2014 12:24, Cameron Stewart  wrote:
> > On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs  wrote:
> >> Have other distros switched to _only_ supporting systemd? Changing the
> >> default is not the same. This is not a rhetorical question - it would
> >> actually be useful to know if other distros have actually already
> >> abandoned support for non-systemd init systems.
> >
> > RHEL/CentOS 7+, Fedora 15+ and Arch Linux have all dropped sysvinit support.
> 
> ArchLinux is clearly dropping sysvinit. RHEL documentation also seems
> to imply that Sysvinit and Upstart are both dropped in 7+.
> 
> Fedora actually is not that decisive, as far as I read here -
> https://fedorahosted.org/fpc/ticket/243

It wasn't 19 months ago, but is petty decisive now:

https://fedorahosted.org/fpc/ticket/359
http://fedoraproject.org/wiki/Packaging:SysVInitScript#Initscripts_in_addition_to_systemd_unit_files

And OpenSUSE also dropped support:

https://www.suse.com/releasenotes/x86_64/openSUSE/12.3/#sec.123.sysv


Kind regards,

Jeroen Dekkers


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87zjcdfxz6.wl%jer...@dekkers.ch

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Josh Triplett]

Aigars Mahinovs wrote:
> Fedora actually is not that decisive, as far as I read here -
> https://fedorahosted.org/fpc/ticket/243

That ticket turned down the suggested policy of "packages MUST NOT
support sysvinit".  That doesn't mean "packages MUST support sysvinit",
or "packages MUST NOT depend on systemd".

The Fedora policy: "Packages may also provide a SysV initscript file,
but are not required to do so."

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030140403.GA498@thin

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 30 October 2014 12:24, Cameron Stewart  wrote:
> On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs  wrote:
>> Have other distros switched to _only_ supporting systemd? Changing the
>> default is not the same. This is not a rhetorical question - it would
>> actually be useful to know if other distros have actually already
>> abandoned support for non-systemd init systems.
>
> RHEL/CentOS 7+, Fedora 15+ and Arch Linux have all dropped sysvinit support.

ArchLinux is clearly dropping sysvinit. RHEL documentation also seems
to imply that Sysvinit and Upstart are both dropped in 7+.

Fedora actually is not that decisive, as far as I read here -
https://fedorahosted.org/fpc/ticket/243

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
 #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDVx=x9WtETQ94rFbTdVdpO2G1QLpJ=+pcpb4iv+gfx...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Cameron Stewart]

On Thu, Oct 30, 2014 at 9:06 PM, Aigars Mahinovs  wrote:
> Have other distros switched to _only_ supporting systemd? Changing the
> default is not the same. This is not a rhetorical question - it would
> actually be useful to know if other distros have actually already
> abandoned support for non-systemd init systems.

RHEL/CentOS 7+, Fedora 15+ and Arch Linux have all dropped sysvinit support.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/caefnlss5pcejdvdemksdhjm_noutv_dh+famx+knxc3jcjo...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 30 October 2014 11:43, Matthias Urlichs  wrote:
> Arguments by popularity are not going to sway anybody here. Otherwise I
> could shut you up with a simple "most other distros have switched and are
> mostly-happy with it". :-P

Have other distros switched to _only_ supporting systemd? Changing the
default is not the same. This is not a rhetorical question - it would
actually be useful to know if other distros have actually already
abandoned support for non-systemd init systems.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
 #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabpywdx8ydwnssejmr3kqmogqj84xvskhai0n5o7lzqvnw1...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Miles Fidelman]

Matthias Urlichs wrote:

Hi,

Florian Lohoff:

There are tons of people who think that all the above functionality does
not belong to a init systemd or ecosystem.


There are also tons of people who could care less, as long as it gets the
job done.

Then there are tons of people who are _very_ happy about the fact that
systemd enables them to do a significant part of their job a whole lot
faster and safer.




And there are tons of people who are very UNHAPPY about the fact that 
systemd requires them to CHANGE how they get their job done.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/54520a7c.8020...@meetinghouse.net

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Adam D. Barratt]

On 2014-10-30 9:43, Matthias Urlichs wrote:

Hi,

Florian Lohoff:
There are tons of people who think that all the above functionality 
does

not belong to a init systemd or ecosystem.

There are also tons of people who could care less, as long as it gets 
the

job done.


fwiw, as this seems to be a commonish error - you mean "could not care 
less". People who could care less by definition do care.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/306a72a7e149b07b8122b4366421e...@mail.adsl.funky-badger.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Matthias Urlichs]

Hi,

Florian Lohoff:
> There are tons of people who think that all the above functionality does
> not belong to a init systemd or ecosystem.
> 
There are also tons of people who could care less, as long as it gets the
job done.

Then there are tons of people who are _very_ happy about the fact that
systemd enables them to do a significant part of their job a whole lot
faster and safer.

There are also tons of people who are simply lazy and think that every
single line of code that the existence of systemd and its ecosystem allows
them to remove, or not write in the first place, is a net win.

Arguments by popularity are not going to sway anybody here. Otherwise I
could shut you up with a simple "most other distros have switched and are
mostly-happy with it". :-P

> It will push
_some_of_
> our users, lobbyists and con-systemd devs away.
> 
Good. The rest of us can then finally focus on our real job(s) again.

> The problem starts with naming all of them systemd-foobar.

You know what? (a) not all of them are, (b) you avoid naming conflicts that
way. Tools which are designed to be universally installable simply can't
have name collisions. I'd very much like to use "nspawn" or some other
cool short name in place of "systemd-nspawn" every time I start a process
in a chroot, but the idea that somebody is already using that command name
for something else isn't too far-fetched.

Thus, IMHO this is a feature.

Of course, if you _insist_ on treating this like an intentional ego-boost,
instigated by systemd's creators, then I can't stop you, just as you can't
prevent me from thinking that you're silly.

> A lot of the oldtimers (like me) would agree to this which i read in rant 
> about systemd:
> 
Arguments by ranting are not going to convince anybody either.
> 
>Because confident young men in a hurry to make their own mark on the
>world have little time for learning the tools or the lessons of the past."
> 
If Lennart's string of talks about systemd at various Linux conferences
during the last couple of years had been a one-way street, he'd not have
been re-invited in the first place, and nobody would have adopted the
thing.

Also, some of us somewhat-old-timers think that the lessons of the past
(and the desire to finally do better, after futzing around the problem
space's periphery for the last twenty years or so) are precisely the reason
why they *like* (most of) what systemd is doing.

> 
> Every time someone tells me about the shiny new features i must think of this.
> 
Every time I read a rant like this, I think that the ranters are unable to
conceive of the fact that people (in particular, Lennart) are actually able
to learn from their mistakes.

Systemd is _not_ like pulseaudio in its infancy.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030094302.gc3...@smurf.noris.de

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Florian Lohoff]

Hi,

On Wed, Oct 29, 2014 at 02:51:57PM +, Marco d'Itri wrote:
> ijack...@chiark.greenend.org.uk wrote:
> 
> >I don't want to be having this conversation again in a year's time,

> > its replacements for syslog,
> You are not required to replace your syslog daemon, and indeed the
> Debian systemd package does not replace it.
> 
> > cron,
> You are not required to replace your cron daemon, and indeed the
> Debian systemd package does not replace it.
> 
> > ntpd,
> You are not required to replace your NTP daemon, and indeed the
> Debian systemd package does not replace it.
> Also, systemd-timesyncd is a simple NTP client and cannot replace ntpd
> anyway except for a trivial (but common) use case.
> 
> > acpid,
> Systemd does not replace acpid.
> 
> Maybe you should try to better understand how systemd actually works 
> before deciding that you do not like it. :-)

There are tons of people who think that all the above functionality does
not belong to a init systemd or ecosystem.

The problem starts with naming all of them systemd-foobar.

It might be a psychological problem but still its a problem for many. By not
listening and repeating the above again and again it will not make the 
resistance
got away. It will push our users, lobbyists and con-systemd devs away.

A lot of the oldtimers (like me) would agree to this which i read in rant about 
systemd:


  "Why replace pam.d, crond, init, and add complexities like dbus in a single
   package that runs at PID1 when it doesn't need to?

   Because confident young men in a hurry to make their own mark on the
   world have little time for learning the tools or the lessons of the past."


Every time someone tells me about the shiny new features i must think of this.

Flo
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Jonathan Dowland]

On Thu, Oct 30, 2014 at 10:32:00AM +0200, Aigars Mahinovs wrote:
> This discussion can end for good in two ways:
> * Debian declares that user choice of init systems is important and
> applications must respect that;
> * Debian declares that only systemd is supported;

The currently GRs appear to be orthogonal to this binary view of the
discussion.


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141030083836.ga7...@chew.redmars.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Florian Lohoff]

Hi,

On Wed, Oct 29, 2014 at 11:10:59AM +0100, Josselin Mouette wrote:
> Which is why sticking to the lowest common denominator among init
> systems is the worst thing we could do as a project.

I would like to stick with lowest common denominator.

Everyone who likes the feature bloat of any software can install it on its own.
But systemd ist a cul de sack. It aglomerates tons of functionality into a
ecosystem where there is no way back.

All the proposals i have read are not going far enough for me. I'd like systemd
to stay out of debian and if introduced only as an addon for those who wish. Its
about choice - This choice is taken from me.


Right now as it is i can replace systemd but i am not able to remove cruft like
systemd-hostname. (Why on earth is this part of systemd anyway?)


I will offer help to anyone willing to start a Debian fork sans systemd.

Flo
PS: It should be common sense to not force these types of controversial changes
to millions of users. The initial debate about systemd showed this before the 
TCs decision.
-- 
Florian Lohoff f...@zz.de


signature.asc
Description: Digital signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 30 October 2014 04:35, Marco d'Itri  wrote:
> ijack...@chiark.greenend.org.uk wrote:
>
>>If my GR fails I expect a series of bitter rearguard battles over
>>individual systemd dependencies.
> This looks like a great way to encourage people to make systemd
> mandatory just to be done with this once and for all... :-)

This discussion can end for good in two ways:
* Debian declares that user choice of init systems is important and
applications must respect that;
* Debian declares that only systemd is supported;

Any other outcome is likely to cause flare-ups for every new feature
that systemd absorbs. And you just need to read Lennart's blog or
watch the video of systemd presentation from Debconf14 to see that
there is a *lot* of new systemd functionality coming up, much of it in
direct conflict with existing tools, much of it providing (or
promising to provide) some superior functionality and new APIs to use
it.

If you trust systemd upstream create these new features in a way that
does not conflict with other implementations *and* not depend on their
own implementations of these features from other parts of systemd code
*and* that other applications will not depend on those new APIs, then
there is nothing to worry about. However, there is an opinion that the
above does not describe how systemd has been developed so far.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
 #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDUX+69dioENKRhzWi8qvtp2nGMmoWf-Hhm-mvHLG=g...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

Ian Jackson  writes:

> That's not the problem.  The problem is the possibility of packages wich
> requires systemd's syslog replacement, its cron replacement, or its ntpd
> replacement.

This isn't a reason for a GR.  This is a reason for Policy saying that
packages must not do that and must instead use our standard syslog, cron,
and ntpd facilities.

(Well, at least the latter two; I think the syslog vs. journald discussion
is more interesting and may depend somewhat on what the package does.  But
we can hash that out as part of the Policy discussion.  I'm certainly in
favor of any package that is logging output and doesn't already have a
hard dependency on systemd services for other reasons needing to have a
fallback to syslog if journald isn't available, at least for the time
being until we see if the landscape seriously changes like it did with
udev, in part because I think that's pretty easy to do.  Maybe someone can
come up with a good reason why that's not the case, but that would
surprise me.  This feels just like socket activation to me; maybe someday
we can all assume socket activation, but in the meantime that's premature,
and having the fallback in place via one means or another is not that
hard.)

I don't understand why you think you need a project-wide vote on such a
thing.  Is there anyone who seriously thinks that packages should switch
to systemd *.timer units *right now* instead of putting files in
/etc/cron.d where all of our current cron systems can process them?
Policy already basically says that /etc/cron.d and related facilities are
how you do this, and I'm happy to second a proposal that makes that a must
for integration purposes.  Maybe that could change in some distant future
that doesn't look like our current situation, but if so, we can change it
when that happens.  The benefits of the systemd facility are minor
compared to the mechanisms we already have in place; there isn't a
logind-style driver to change ways of handling this.

I highly doubt this would even be controversial.

You seem to be both borrowing trouble and hitting it with nuclear weapons.
I assume this is coming out of your strong belief that systemd upstream is
on a crusade to replace everything, but I don't think that worry is in
much contact with reality here.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ppdaclgz@hope.eyrie.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Marco d'Itri]

ijack...@chiark.greenend.org.uk wrote:

>If my GR fails I expect a series of bitter rearguard battles over
>individual systemd dependencies.
This looks like a great way to encourage people to make systemd
mandatory just to be done with this once and for all... :-)

>That's not the problem.  The problem is the possibility of packages
>wich requires systemd's syslog replacement, its cron replacement, or
>its ntpd replacement.
It is not clear why a program would want to depend on any of these
components, so you are scared about something that is at best
hypotetical.

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2s85t$rji$1...@posted-at.bofh.it

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Josh Triplett]

Ian Jackson wrote:
> Marco d'Itri writes ("Re: Legitimate exercise of our constitutional 
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > ijack...@chiark.greenend.org.uk wrote:
> > >I don't want to be having this conversation again in a year's time,
> >
> > And still, I am ready to bet that we will...
> 
> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.
> 
> If my GR fails I expect a series of bitter rearguard battles over
> individual systemd dependencies.

In other words, if you win, everyone should just shut up and "respect
the project's collective decision", but if you lose, you intend to keep
fighting over every systemd feature you possibly can rather than
"respecting the project's collective decision"?

If you do not expect the vote on this GR and its collective amendments
to actually *end* this interminable issue and let people get back to
work, whichever outcome the project determines, what collective action
*would* have that effect, and could we get that on the ballot?

I tend to agree with Charles Plessy's simple statement that everything
is working just fine, but now I'm starting to wonder if Luca Falavigna's
proposal to *explicitly* say "go ahead and depend on an init system if
needed" would provide more closure on this issue.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029221821.GA17894@jtriplet-mobl1

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ondřej Surý]

On Wed, Oct 29, 2014, at 20:03, Matthias Urlichs wrote:
> And if that happens with journald, I fully expect that somebody will step
> up and provide a replacement implementation (either of the daemon, or the
> underpinnings it needs) that works without systemd-as-pid1. Just like
> systemd-shim.

Speaking with my Knot DNS hat - we have added support for journald
logging just because we can add additional information to the log line
information like the affected zone or type of service, and you can
filter the log for those logs after that.

And I don't really see that as a vendor lock-in, but simply a superior
implementation.

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


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/1414610346.414024.184812557.3eea9...@webmail.messagingengine.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Matthias Urlichs]

Hi,

Ian Jackson:
> If my GR passes we will only have to have this conversation if those
> who are outvoted do not respect the project's collective decision.
> 
As opposed to us having this discussion _now_ because some people
apparently cannot accept the fact that Debian works quite well
without it. (Otherwise there would be no "systemd-shim".)

> If my GR fails I expect a series of bitter rearguard battles over
> individual systemd dependencies.
> 
No fear-mongering, please.

> That's not the problem.  The problem is the possibility of packages
> wich requires systemd's syslog replacement, its cron replacement, or
> its ntpd replacement.
> 
systemd does not replace syslog. It adds its own logging system which,
like logind (and the logind back-end service implemented by
systemd-as-PID1), adds features which some programmers, like 
those of Gnome/KDE/whoever, want to rely on – not out of spite,
but because it makes their job a whole lot easier.

And if that happens with journald, I fully expect that somebody will step
up and provide a replacement implementation (either of the daemon, or the
underpinnings it needs) that works without systemd-as-pid1. Just like
systemd-shim.

And this will happen without requiring your GR. Just like systemd-shim.

> This is what system's opponents are calling `lock-in'.  I agree.
> 
This is not lock-in. Lock-in is Adobe pushing a closed standard like Flash
(random example off the top of my head, not intended to be particular to
Adobe) and then refusing to publish the specs.

Debian is free software. If you want a second implementation which does
what you want, the way you want it, then write it yourself. Or motivate
somebody else to do it.

A GR which forces my code to be compatible with Y, even if X is included in
Debian (worse, even if X is the designated stanard way to do 
in Debian), is not an acceptable form of motivation to me.

I also may be missing something, but in what way would "my code is in
Debian, but if you want to run it you'll have to use X instead of Y"
in any way better for our users than "my code is not in Debian"?
(Assuming it's useful and otherwise desireable code, of course. :-P )

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029190303.gb3...@smurf.noris.de

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Adam D. Barratt]

On 2014-10-29 16:13, Ian Jackson wrote:

Marco d'Itri writes ("Re: Legitimate exercise of our constitutional
decision-making processes [Was, Re: Tentative summary of the
amendments]"):

ijack...@chiark.greenend.org.uk wrote:
>I don't want to be having this conversation again in a year's time,

And still, I am ready to bet that we will...


If my GR passes we will only have to have this conversation if those
who are outvoted do not respect the project's collective decision.

If my GR fails I expect a series of bitter rearguard battles over
individual systemd dependencies.


Please, let's be fair. If the GR fails, we will only have to have this 
conversation if those who are outvoted do not respect the project's 
collective decision.


Regards,

Adam


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/13915ce5f940324ac2b3285d1c99e...@mail.adsl.funky-badger.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ian Jackson]

Marco d'Itri writes ("Re: Legitimate exercise of our constitutional 
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> ijack...@chiark.greenend.org.uk wrote:
> >I don't want to be having this conversation again in a year's time,
>
> And still, I am ready to bet that we will...

If my GR passes we will only have to have this conversation if those
who are outvoted do not respect the project's collective decision.

If my GR fails I expect a series of bitter rearguard battles over
individual systemd dependencies.

> > cron,
>
> You are not required to replace your cron daemon, and indeed the
> Debian systemd package does not replace it.

That's not the problem.  The problem is the possibility of packages
wich requires systemd's syslog replacement, its cron replacement, or
its ntpd replacement.

The problem is the prospect of having to switch init to systemd in
order to get some package's spport for network time working properly,
or whatever.

This is what system's opponents are calling `lock-in'.  I agree.

Ian.


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Holger Levsen]

On Mittwoch, 29. Oktober 2014, Ian Jackson wrote:
> In the battle between those upstreams and Debian contributors [...]

please, don't mention the war.


signature.asc
Description: This is a digitally signed message part.

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Neil McGovern]

On Wed, Oct 29, 2014 at 12:27:40PM +, Ian Jackson wrote:
> Neil McGovern writes ("Re: Legitimate exercise of our constitutional 
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
> > As far as I'm aware, we don't actually say that anywhere. Applications can
> > only /rely/ on those interfaces, but it's certainly possible for an
> > application to have a Depends: on a particular shell.
> 
> You can have more than one shell.  In fact you can have as many as you
> like.
> 
> We do *not* allow applications to require a particular shell
> *to be /bin/sh*.
> 

Indeed, but we do allow applications to rely on other particular things
to be running, such as the kernel, or the bootloader. That said, I think
we're moving off the point, which is that the extension of the sh bit of
policy to this GR is one I don't think can be relied on.

Neil


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029144959.gl18...@halon.org.uk

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Marco d'Itri]

ijack...@chiark.greenend.org.uk wrote:

>I don't want to be having this conversation again in a year's time,
And still, I am ready to bet that we will...

>with those upstreams and their like-minded Debian contributors saying
>things like `it is too late now; the world has moved on'.
It is *already* too late: it is a fact that the rest of the relevant
world has moved on and has adopted systemd.

>I am personally not a great fan of sysvinit.  This argument is not
>really about service startup, though.  It's about
> systemd's graphical console management,
Kernel developers have been explaining for years that we need a user
space console to properly support things that are not well supported
now, and I do not see anybody else writing one...

> its replacements for syslog,
You are not required to replace your syslog daemon, and indeed the
Debian systemd package does not replace it.

> cron,
You are not required to replace your cron daemon, and indeed the
Debian systemd package does not replace it.

> ntpd,
You are not required to replace your NTP daemon, and indeed the
Debian systemd package does not replace it.
Also, systemd-timesyncd is a simple NTP client and cannot replace ntpd
anyway except for a trivial (but common) use case.

> acpid,
Systemd does not replace acpid.

Maybe you should try to better understand how systemd actually works 
before deciding that you do not like it. :-)

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2quub$s94$1...@posted-at.bofh.it

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Neil McGovern]

On Wed, Oct 29, 2014 at 02:16:14PM +0200, Aigars Mahinovs wrote:
> On 29 October 2014 13:40, Neil McGovern  wrote:
> >> * if we go the MTA/sh route, then we define lowest common denominator
> >> interface of an init system and only init systems providing that
> >> (possibly with a systemd-shim) can be init systems in the archive and
> >> also applications can only depend on presence of these particular
> >> interfaces;
> >
> > I think there's possibly a slight logic gap here, and that's around
> > "applications can only depend on presence of these particular interfaces".
> >
> > As far as I'm aware, we don't actually say that anywhere. Applications can
> > only /rely/ on those interfaces, but it's certainly possible for an
> > application to have a Depends: on a particular shell.
> 
> Shell is relatively harmless, imagine if, for example, LibreOffice
> suddenly had a dependency on Exim (due to some special email sending
> options used in the mail merge feature) and so installing LibreOffice
> would also change your MTA.
> 

Or, if you installed memtest86, and it replaced lilo by installing grub?
:)

My point is that I believe that we should be clear what we're saying
here. I don't think that (as a project) we've said quite so strongly
that program X may only use Y features, or are restricted from declaring
a Depends: line.
That is quite different to the comment above about defining a lowest
common denominator, which is not (as far as I can tell) what this GR is
about.

Neil


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141029144023.gk18...@halon.org.uk

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ian Jackson]

Neil McGovern writes ("Re: Legitimate exercise of our constitutional 
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> As far as I'm aware, we don't actually say that anywhere. Applications can
> only /rely/ on those interfaces, but it's certainly possible for an
> application to have a Depends: on a particular shell.

You can have more than one shell.  In fact you can have as many as you
like.

We do *not* allow applications to require a particular shell
*to be /bin/sh*.

Ian.


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ian Jackson]

Philip Hands writes ("Re: Legitimate exercise of our constitutional 
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> I thought you said that your GR (i.e. option 1) was effectively a NOP
> for Jessie (that's certainly how I read the text of your clause 4)

Indeed.

> in which case the people that would prefer to avoid systemd have
> several years (until the end of jessie-LTS) to come up with
> alternatives that they prefer, so there is absolutely no reason to
> panic about it now.

I think this is a misreading of the situation.  Encouraged by
systemd's vigorous and effective marketing campaign, changes by (some)
upstreams to introduce dependencies on facilities bundled with systemd
will continue apace.

I don't want to be having this conversation again in a year's time,
with those upstreams and their like-minded Debian contributors saying
things like `it is too late now; the world has moved on'.

> If we were to adopt Option 1, then we'll be dragging sysvinit behind us
> like a ball and chain long past the last person who clung to it notices
> that there are better alternatives available -- which presumably will
> come to pass eventually (or more likely happened some time ago, but the
> inertia in Debian is blinding us to that fact).

I am personally not a great fan of sysvinit.  This argument is not
really about service startup, though.  It's about systemd's graphical
console management, its replacements for syslog, cron, ntpd, acpid,
etc etc etc.

Certainly there is nothing in this GR that would prevent us dropping
sysvinit.  But there is obviously plenty of effort available for
keeping sysvinit - as an init system - working.  That's not the real
problem.

> Also, they'll be doing all that under duress, so will likely be irritable
> when anyone asks them to support a third init, whereas without this
> meddling in the natural order they'd probably be quite interested to
> adopt an emerging competitor to systemd that supports their needs.

In the battle between those upstreams and Debian contributors who want
everyone to use systemd, and those developers and users who don't want
to use systemd, _someone_ is going to experience duress.

The question is who.


systemd's adoption strategy combines vigorous and effective PR with
expansive bundling, and repeated assertions that systemd's competitors
(and I don't mean sysvinit) are obsolete and/or unsupportable.

This is a novel approach in the Free Software world.  Traditionally
Free Software developers have attempted to win by convincing /users/
that their software is superior, rather than by convincing
/developers/ that there is no credible alternative.

It's not surprising that we're having a political storm as a result.
And it's not surprising that the biggest howls are from users rather
than developers.  After all, the systemd adoption strategy
disenfranchises users - just as Debian's governance process does.

Ian.


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 29 October 2014 13:40, Neil McGovern  wrote:
>> * if we go the MTA/sh route, then we define lowest common denominator
>> interface of an init system and only init systems providing that
>> (possibly with a systemd-shim) can be init systems in the archive and
>> also applications can only depend on presence of these particular
>> interfaces;
>
> I think there's possibly a slight logic gap here, and that's around
> "applications can only depend on presence of these particular interfaces".
>
> As far as I'm aware, we don't actually say that anywhere. Applications can
> only /rely/ on those interfaces, but it's certainly possible for an
> application to have a Depends: on a particular shell.

Shell is relatively harmless, imagine if, for example, LibreOffice
suddenly had a dependency on Exim (due to some special email sending
options used in the mail merge feature) and so installing LibreOffice
would also change your MTA.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
 #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabpywduykkm8bqcxrjreaxaqg12sxhhtc1jj5-ocedikn02...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Neil McGovern]

On Tue, Oct 28, 2014 at 06:31:43PM +0200, Aigars Mahinovs wrote:
> On 28 October 2014 18:20, Russ Allbery  wrote:
> > With all of those facilities, we've taken different approaches; with the
> > mail transport agent, for example, we've defined an interface that all
> > mail transport agents are required to implement, and MTA implementations
> > that don't implement that interface aren't allowed to provide a mail
> > transport agent.  We did something similar with /bin/sh.  With udev, on
> > the other hand, we basically required everyone run udev; it's
> > theoretically possible to boot a system without udev, but it's not tested
> > and I think everyone would agree that it's not supported.  For the
> > compiler, all of Debian is built with GCC, but some teams do test builds
> > with Clang and report bugs, which most maintainers merge and some don't.
> > And with libc, we do not even allow for the possibility of replacing the
> > system libc; you use glibc if you're using Debian on Linux, and that's the
> > end of that.
> 
> This is an interesting insight. It also can be used to identify
> possible solutions for the current issue:
> * if we go the MTA/sh route, then we define lowest common denominator
> interface of an init system and only init systems providing that
> (possibly with a systemd-shim) can be init systems in the archive and
> also applications can only depend on presence of these particular
> interfaces;
> * if we go udev/gcc/glibc route, then we just say that all other init
> systems are not supported, put systemd as essential and push all other
> init systems to extra or even out of the archive;
> 
> With enough imagination it is possible to see the original GR proposal
> as implementing the first option in a obtuse way.

I think there's possibly a slight logic gap here, and that's around
"applications can only depend on presence of these particular interfaces".

As far as I'm aware, we don't actually say that anywhere. Applications can
only /rely/ on those interfaces, but it's certainly possible for an
application to have a Depends: on a particular shell.
From Policy 10.4:
"If a shell script requires non-SUSv3 features from the shell
interpreter other than those listed above, the appropriate shell must be
specified in the first line of the script (e.g., #!/bin/bash) and the
package must depend on the package providing the shell (unless the shell
package is marked "Essential", as in the case of bash)."

Going down the minimal standard would mean that we should codify in
policy what we expect the minimal standard of the init system to have to
be in the archive, but what this GR seems to be about is saying that
applications may or may not actually have that Depends: at all.

Neil
-- 


signature.asc
Description: Digital signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ian Jackson]

Aigars Mahinovs writes ("Re: Legitimate exercise of our constitutional 
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> This is an interesting insight. It also can be used to identify
> possible solutions for the current issue:
>
> * if we go the MTA/sh route, then we define lowest common denominator
> interface of an init system and only init systems providing that
> (possibly with a systemd-shim) can be init systems in the archive and
> also applications can only depend on presence of these particular
> interfaces;

That would be a fine resolution to the problem.

> With enough imagination it is possible to see the original GR proposal
> as implementing the first option in a obtuse way.

My GR proposal does not describe technical solutions.  That would be a
terrible idea in a GR.  The resolution sets out some consequences if
the technical problems are not resolved.

Ian.


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Josselin Mouette]

Hi,

Le mercredi 29 octobre 2014 à 09:22 +, Philip Hands a écrit :
> Of course, for the likes of Gnome, voting for Option 1 really will have
> an immediate effect, which will be to completely demotivate our Gnome
> maintainers, since this would be a vote against them.
> 
> I think Debian without Gnome would be a diminished thing, and that seems
> like a reasonably likely outcome of Option 1 passing.

I agree with most of what you said, but I really have to point out that
this is not just about GNOME. In the current state of affairs, it is
about GNOME, KDE, Xfce, MATE and Cinnamon. Basically any use of Debian
on a desktop with 21st century features.

And, even more importantly in my opinion, it is about having a modern
init system that is suitable for embedded developers and server
administrators. It is about being able to package server software
without asking yourself how many bugs there are in your init script. To
reduce development load by sharing non-Debian-specific things with other
distributions.

Which is why sticking to the lowest common denominator among init
systems is the worst thing we could do as a project.

> If nobody cares to do the work, there is no need for it to be done.

Amen to that, a thousand times.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414577459.4977.7.ca...@kagura.malsain.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Philip Hands]

[cross-post to -project dropped]

Hi Ian,

Ian Jackson  writes:

> Thanks to Steve for his perceptive and well-reasoned article.
>
> Steve Langasek writes ("Legitimate exercise of our constitutional 
> decision-making processes [Was, Re: Tentative summary of the amendments]"):
>> There are also a lot of Debian users who are afraid of what the future holds
>> for an OS that they love very much; and they deserve to have that cloud of
>> fear removed from over their heads, to be given closure, even if that
>> closure brings the certainty that they will part ways with Debian rather
>> than being reconciled to it.
>
> There is a big point I wanted to make apropos, roughly, of this:
>
> If this vote goes against the users and derivatives who don't want to
> use systemd, those people will have nowhere to go.

I thought you said that your GR (i.e. option 1) was effectively a NOP
for Jessie (that's certainly how I read the text of your clause 4) in
which case the people that would prefer to avoid systemd have several
years (until the end of jessie-LTS) to come up with alternatives that
they prefer, so there is absolutely no reason to panic about it now.

If we were to adopt Option 1, then we'll be dragging sysvinit behind us
like a ball and chain long past the last person who clung to it notices
that there are better alternatives available -- which presumably will
come to pass eventually (or more likely happened some time ago, but the
inertia in Debian is blinding us to that fact).

The network effect that Steve tried to conjure for systemd will actually
come into effect, but for sysvinit, because the few people that might
have a good reason to depend on systemd-as-init will be forced to cobble
something together for sysvinit to act as a shield against the newly
created RC missiles.  I cannot see them being very motivated to maintain
that sysvinit-shield though, so we should expect those to rot over time.

Also, they'll be doing all that under duress, so will likely be irritable
when anyone asks them to support a third init, whereas without this
meddling in the natural order they'd probably be quite interested to
adopt an emerging competitor to systemd that supports their needs.

The result being that we'll be tied to sysvinit way beyond it's usefulness.

Of course, for the likes of Gnome, voting for Option 1 really will have
an immediate effect, which will be to completely demotivate our Gnome
maintainers, since this would be a vote against them.

I think Debian without Gnome would be a diminished thing, and that seems
like a reasonably likely outcome of Option 1 passing.

That's why I'll be voting for Charles' amendment (Option 4).

The mechanisms we already have will continue to serve us to resolve any
real instances of the breakage you're worried about.  If there are
enough people that care, Gnome will be made to run without systemd.  If
not, not, and in that case very few people will care.  If nobody cares
to do the work, there is no need for it to be done.

Option 1 seems like a Luddite reaction to me, which is of course very
tempting to the grey-bearded unix user in me, but I'd suggest that that
is just a symptom of old age, so the temptation should be resisted IMO.

If we cannot embrace innovation we should get out of the way of the
youngsters, whose brains are yet to fossilise, and see what wonders they
can surprise us with.

It may not be as awful as you imagine.

Cheers, Phil.

P.S. for those of you busily making assumptions about what my motives
are: I'm an xmonad user, have only recently installed systemd on my
laptop (with some minor issues that will get reported as bugs once I
track them down), and rarely manage to install Gnome to my satisfaction
(because I'm generally trying with old hardware), so on the whole this
doesn't affect me greatly either way (apart from the vast waste of time
involved in following the interminable arguments).
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,GERMANY


pgppxSvtWyV0j.pgp
Description: PGP signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Didier 'OdyX' Raboud]

(Dropping -project)

Le mardi, 28 octobre 2014, 17.26:32 Ian Jackson a écrit :
> Thanks to Steve for his perceptive and well-reasoned article.
> 
> Steve Langasek writes:
> > There are also a lot of Debian users who are afraid of what the
> > future holds for an OS that they love very much; and they deserve
> > to have that cloud of fear removed from over their heads, to be
> > given closure, even if that closure brings the certainty that they
> > will part ways with Debian rather than being reconciled to it.
> 
> There is a big point I wanted to make apropos, roughly, of this:
> 
> If this vote goes against the users and derivatives who don't want to
> use systemd, those people will have nowhere to go.

It would be nice (and, I think, more honest) if you refrained from 
framing this GR as a "vote in favour or against the (people) who don't 
want to use systemd": your amendment doesn't say anything in this 
regard, and none of the others say so either. By framing the GR in this 
light, it seems to me that you're trying to paint anyone not voting your 
proposal first as "against non-systemd users", which I feel as unfair 
and dishonest.

Several amendments in this GR are indeed saying "whoever doesn't want to 
use systemd in Debian should be putting up the work to make it happen", 
but none of that is "voting against the (people) who don't want to use 
systemd".

OdyX


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/4664676.peOt7Kkscx@gyllingar

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Sam Hartman]

Steve, thanks for writing up your note.

I strongly agree that Ian's resolution is legitimate.  It's not a abuse
of process, it's reasonably to bring forward.

I also think Charles's amendment is legitimate in the same sense: to say
that we as a community do not choose to act as a community in this
matter.

I don't know how the vote will go, but I believe that all the DDs I've
seen interacting in this process are acting in legitimate good-faith
within our decision making system.

--Sam


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/0149589505fd-be3ec904-9f83-4c24-8f44-222a6158861c-000...@email.amazonses.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

Josselin Mouette  writes:
> Russ Allbery  wrote: 

> If GNOME supported being built without those features, yes, it's
> fairly straightforward.  I probably overstated it by saying it's
> trivial, but I don't think it would be that hard.  But that's
> from the *packaging* perspective, which is the part of the
> ecosystem that you were addressing.
> 
> GNOME upstream has not chosen to make those features optional,
> for reasons of maintainability at their end, so it's not
> trivial, but not for any packaging reasons.  Rather, it's not
> trivial because the support for acceptable degraded operation
> without that functionality is not available in the upstream code
> base so far as I know.  (GNOME maintainers should correct me
> here if I got the situation wrong.)

> I haven’t tested, but I think you can start a GNOME session without
> systemd-logind and do some basic things. It’s just that the amount of
> functionality that is not available makes it unacceptable. Things like
> power management (including being able to suspend or shut down), or
> network roaming, are not optional except in special cases. You cannot
> ship that and expect users to consider it “working”.

Ah, okay, so it's not quite as complete as I had thought, but the level of
functionality missing from the non-logind branch is sufficiently huge that
it's not clear that the resulting packages would be considered useful, or
considered GNOME.  I think it's fair to call that software that's not been
ported to a non-logind world.  The porting effort that we're currently
doing is to port logind to sysvinit, rather than trying to port GNOME to
something other than logind.

I seem to recall some discussion in release-team about the status of GNOME
on kFreeBSD, which should provide a reasonable glimpse into what GNOME
looks like without logind (although it may have even more issues on
kFreeBSD than on Linux without logind since a few other things are also
different).

> This is mostly about functionality that used to be provided by
> ConsoleKit. Note that the primary GNOME component affected, which is
> GDM, has fallback code for ConsoleKit at runtime. However, everything
> else depends on PolicyKit, which has chosen to only allow one of both at
> build time. But this is a choice of fd.o developers, not GNOME ;)

Whoops, sorry, I had forgotten that there are multiple upstreams involved
here who are making various different choices about what's supported.

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


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87ioj4gc48@hope.eyrie.org

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Josselin Mouette]

Russ Allbery  wrote: 
If GNOME supported being built without those features, yes, it's fairly
straightforward.  I probably overstated it by saying it's trivial, but I
don't think it would be that hard.  But that's from the *packaging*
perspective, which is the part of the ecosystem that you were 
addressing.

GNOME upstream has not chosen to make those features optional, for 
reasons
of maintainability at their end, so it's not trivial, but not for any
packaging reasons.  Rather, it's not trivial because the support for
acceptable degraded operation without that functionality is not 
available
in the upstream code base so far as I know.  (GNOME maintainers should
correct me here if I got the situation wrong.)

I haven’t tested, but I think you can start a GNOME session without
systemd-logind and do some basic things. It’s just that the amount of
functionality that is not available makes it unacceptable. Things like
power management (including being able to suspend or shut down), or
network roaming, are not optional except in special cases. You cannot
ship that and expect users to consider it “working”. 

This is mostly about functionality that used to be provided by
ConsoleKit. Note that the primary GNOME component affected, which is
GDM, has fallback code for ConsoleKit at runtime. However, everything
else depends on PolicyKit, which has chosen to only allow one of both at
build time. But this is a choice of fd.o developers, not GNOME ;) 

Cheers,
-- 
Joss



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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[The Wanderer]

On 10/28/2014 at 12:20 PM, Russ Allbery wrote:

> The Wanderer  writes:
> 
>> What I'm thinking of is cases where upstream has decided to depend
>> on functionality that is provided by one init system but not by
>> others, without graceful runtime fallback - compile-time choices,
>> essentially, where functionality is omitted if the init system is
>> not present. I have had the impression that GNOME is one such
>> upstream, to whatever extent it has not dropped support for
>> non-systemd environments entirely.
> 
> But that's not the same sort of thing at all.
> 
> You were talking about how to package software that supports
> multiple kernels or multiple architectures but with different
> capabilities on those different kernels or architectures.  We have
> packaging tools to deal with that, yes.  We have similar packaging
> tools to deal with software that supports multiple init systems with
> different capabilities.  It's a mostly solved problem.

Is it? I thought part of the problem is that there are packages whose
upstream supports (or at least enables) compiling with / without
integration to functionality provided by systemd, and which are provided
in Debian only as compiled with that functionality enabled, with no
alternative package which omits that functionality. I had the impression
that GNOME was one such (set of) package(s).

It seems unlikely to me that such exclusivity would occur if packaging
for both in parallel (and handling dependencies on the parallel
packages) were a "solved problem" in that way.

Certainly I know of no functionality to make it easy or automated to
provide such packages, comparable to e.g. the multiarch package
labeling...

> You're now talking about packages that *do not* support multiple
> init systems at all, but instead rely on capabilities that are
> specific to one init system.

Actually, I'm talking both about software which has been (as you put it)
"ported" to support multiple init systems and, separately, about
software which has not.

My idea was approximately that the former could be addressed by an
analog of the multi-arch "parallel packages" model, with multiple binary
packages from the same source package, and the latter could be addressed
by "simply" having the package manager not 'see' a particular package as
being available for installation unless the environment is such that the
features are expected to be provided - a stronger version of a hard
dependency.


The latter of those two hypothetical approaches was based on what now
appears to have been a mistaken impression about the way kernel-category
dependencies are handled currently.

How does software which requires the features of a particular kernel
currently depend on having that particular kernel active? I would have
expected it to be via a dependency on 'linux-image' or 'kfreebsd-image'
or the like, but at a glance I don't see my current linux-image-*
package providing any such virtual package, and offhand I don't know of
any kernel-dependent packages except for systemd - which does not
obviously appear to express any kernel-related dependency.

If such software effectively does not so depend, instead choosing to
simply fail at runtime, that would be a somewhat odd design choice but
might be one we could emulate for init systems... I'm not sure I'd
support that approach even if so, though.

>> And that's entirely my point: something which depends on a feature
>> provided by a kernel or an architecture, such that it won't build /
>> run properly on anything that doesn't provide that feature, can be
>> packaged either so as to be compiled with support for the feature
>> in environments which provide it and without support for it in
>> environments which don't or so as to be available (package visible
>> to the package manager) in environments where the feature is
>> available and not in ones where it is not - but something which
>> depends on a feature provided by an init system cannot AFAIK be
>> packaged in a comparably varying way, with the current packaging
>> infrastructure.
> 
> This is a bad comparison.  You're comparing software that has been
> ported to multiple architectures (with some degredation of
> capabilities) to software that has not been ported to multiple init
> systems at all.  You can't do that and arrive at any meaningful
> conclusions; you're comparing apples to oranges.

I thought I'd adequately allowed for both sides of that? The "software
that has been ported" would fall under "can be packaged so as to be
compiled with / without support", and the "software that has not been
ported" would fall under "can be packaged so as for the package to be
available when the functionality is and not when the functionality is
not". Is that not enough?

There would certainly be obstacles, possibly prohibitive ones, to
implementing the latter - beyond just the "package depends on
package-which-sets-X-as-init-system" approach which is what has been
being used so far, and which has its alrea

Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Ian Jackson]

Thanks to Steve for his perceptive and well-reasoned article.

Steve Langasek writes ("Legitimate exercise of our constitutional 
decision-making processes [Was, Re: Tentative summary of the amendments]"):
> There are also a lot of Debian users who are afraid of what the future holds
> for an OS that they love very much; and they deserve to have that cloud of
> fear removed from over their heads, to be given closure, even if that
> closure brings the certainty that they will part ways with Debian rather
> than being reconciled to it.

There is a big point I wanted to make apropos, roughly, of this:

If this vote goes against the users and derivatives who don't want to
use systemd, those people will have nowhere to go.

It's clear that the systemd project has been vigorously expanding its
range of functionality.  It now contains competitors to (amongst many
other things) syslog, cron and ntpd.

If Debian packages in general start to depend on the systemd versions
of these services, and support is removed for interacting with and
configuring the non-systemd services (cron.d snippets, for example),
it will be very difficult for a downstream distro to put back support
for operation without systemd.  That would involve a very large number
of patches to things like maintainer scripts.


Conversely, what if, following the passage of my GR, the very unlikely
worst case comes to pass - some packages can't be made to work
properly without systemd, and those packages are removed from Debian ?
In such a situation would be very easy for downstreams to put them
back.  I think such a derivative would be straightforward project and
sustainable in the long term.

But as I say I don't think it will come to that.  With appropriate
backpressure both the doomsday scenarios can be avoided.


I think that as the upstream for our community, we have a
responsibility to make our distribution as flexible as possible.

And over the years we have discharged that responsibility amazingly
well.  At one end of the spectrum Debian has developed some very
sophisticated frameworks for handling the diversity of software; and
at the other end, our individual packages often contain features big
and small which are useful only in non-default configurations - even,
features useful only in esoteric situations.

This flexibility has, for a long time, been one of our key strengths.
It is one of the reasons we are an attractive choice for downstreams
and it is also something that I have always thought the Debian
community values highly.

We have even encoded that flexibility in the slogan `the Universal
Operating System'.  That surely does not mean that Debian /is/, itself
and directly, the best OS for every purpose; but rather than Debian is
at least trying to support every possibility, all imperfectly.  We try
to avoid trading off that flexibility in favour of supporting some (or
even many) use cases more perfectly.

Ian.


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

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 28 October 2014 18:20, Russ Allbery  wrote:
> With all of those facilities, we've taken different approaches; with the
> mail transport agent, for example, we've defined an interface that all
> mail transport agents are required to implement, and MTA implementations
> that don't implement that interface aren't allowed to provide a mail
> transport agent.  We did something similar with /bin/sh.  With udev, on
> the other hand, we basically required everyone run udev; it's
> theoretically possible to boot a system without udev, but it's not tested
> and I think everyone would agree that it's not supported.  For the
> compiler, all of Debian is built with GCC, but some teams do test builds
> with Clang and report bugs, which most maintainers merge and some don't.
> And with libc, we do not even allow for the possibility of replacing the
> system libc; you use glibc if you're using Debian on Linux, and that's the
> end of that.

This is an interesting insight. It also can be used to identify
possible solutions for the current issue:
* if we go the MTA/sh route, then we define lowest common denominator
interface of an init system and only init systems providing that
(possibly with a systemd-shim) can be init systems in the archive and
also applications can only depend on presence of these particular
interfaces;
* if we go udev/gcc/glibc route, then we just say that all other init
systems are not supported, put systemd as essential and push all other
init systems to extra or even out of the archive;

With enough imagination it is possible to see the original GR proposal
as implementing the first option in a obtuse way.
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
 #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDWj6SK6k22=okmy3lm8txfey3n4b9ge+c9edo90bpa...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

The Wanderer  writes:

> What I'm thinking of is cases where upstream has decided to depend on
> functionality that is provided by one init system but not by others,
> without graceful runtime fallback - compile-time choices, essentially,
> where functionality is omitted if the init system is not present. I have
> had the impression that GNOME is one such upstream, to whatever extent
> it has not dropped support for non-systemd environments entirely.

But that's not the same sort of thing at all.

You were talking about how to package software that supports multiple
kernels or multiple architectures but with different capabilities on those
different kernels or architectures.  We have packaging tools to deal with
that, yes.  We have similar packaging tools to deal with software that
supports multiple init systems with different capabilities.  It's a mostly
solved problem.

You're now talking about packages that *do not* support multiple init
systems at all, but instead rely on capabilities that are specific to one
init system.  That's a completely different problem, and not a problem
that can be solved by some sort of packaging infrastructure.  That's a
straight porting problem, such as a software package that only builds on
amd64.  Nothing about our packaging environment is going to help with
that: it's simply (possibly quite hard) work.  And that's similarly true
of packages that *rely* on one particular kernel, such as all the
Linux-specific software we have in the archive that doesn't work on
FreeBSD.

Supporting multiple init systems in packaging given upstream support for
building for different init systems is easy.  *Porting* is hard, and there
are no packaging shortcuts for that.  Which is why we're having a debate
over whether to allow unported software in the archive.

As AJ pointed out, we've been allowing unported software in the archive
for years and years.  We have lots of software that only builds on a
subset of architectures, or is specific to Linux, or is specific to
FreeBSD.  It's not at all clear to me why init systems should be any
different.

> And that's entirely my point: something which depends on a feature
> provided by a kernel or an architecture, such that it won't build / run
> properly on anything that doesn't provide that feature, can be packaged
> either so as to be compiled with support for the feature in environments
> which provide it and without support for it in environments which don't
> or so as to be available (package visible to the package manager) in
> environments where the feature is available and not in ones where it is
> not - but something which depends on a feature provided by an init
> system cannot AFAIK be packaged in a comparably varying way, with the
> current packaging infrastructure.

This is a bad comparison.  You're comparing software that has been ported
to multiple architectures (with some degredation of capabilities) to
software that has not been ported to multiple init systems at all.  You
can't do that and arrive at any meaningful conclusions; you're comparing
apples to oranges.

The comparison for init systems that would actually be equivalent is
software that supports socket activation but falls back on binding its own
sockets; that's equivalent to software that works on multiple
architectures with some degredation of capabilities.  Those packages are
uncontroversial in this whole debate.

The controversy is all about software that isn't portable, software that
does the init system equivalent of requiring the Linux kernel.  Such
software wouldn't work on FreeBSD without substantial work rebuilding the
same features or writing glue libraries for FreeBSD.  The approach we've
taken with such software in the archive in the past is to just mark it as
Linux-only until someone has a chance to port it.  That's controversial
for init systems, so far as I can tell, mostly because the platform to
which the software has not been ported is more widely used, and the
software used to be portable to other init systems but the portability was
dropped upstream as unmaintainable.  But, technically, it's basically the
same problem.

> In the past, we have had two major things of which you can only have
> one, of which every system must have one, and which provide differing
> feature sets in a way which can matter at runtime: the running kernel,
> and the CPU architecture.

No, there are lots of things like that.  Other major things of which you
have only one include libc, udev, a mail transport agent, the compiler,
and /bin/sh, just off the top of my head.  I'm sure there are many more.

With all of those facilities, we've taken different approaches; with the
mail transport agent, for example, we've defined an interface that all
mail transport agents are required to implement, and MTA implementations
that don't implement that interface aren't allowed to provide a mail
transport agent.  We did something similar with /bin/sh.  With udev, on
the other hand, we basica

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Aigars Mahinovs]

On 28 October 2014 04:29, Anthony Towns  wrote:
> The corresponding question for services versus init systems would be:
>
>  - package "foo" has a .service file upstream, but no init script
>  - Alice packages foo, doesn't write an init script, and uploads it to 
> unstable
>  - it's automatically accepted to unstable
>  - upstart user Bob files a bug requesting an init script, but doesn't
> provide a patch
>  - Alice says "just use systemd" and still doesn't write an init script
>
> with the question being "does release manager Carol stop the package
> from being released"?
>
> AIUI, policy hasn't ever made not having an init script an RC bug

Please, do not confuse the issue again - this is *not* about a package
having init scripts for a particular init system. It is about a
package being able to function at all (even if started manually) when
a particular init system is running as PID 1. That is a completely new
issue that has never been a problem for any software before.

A per the terms of the original GR proposal, not having an init script
for an alternative init system would be a bug with the same severity
as if it affected all users, so somewhere from 'wishlist' to at most
'normal'.
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabpywduebsywrx6hf7ho2kfgeyss_8+m_y4d1am775qfnkm...@mail.gmail.com

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[The Wanderer]

(I wonder about the extent to which this remains on-topic... I didn't
hesitate about my previous post, since it was relatively brief and
addressed what I thought was an important and relevant single point, but
this is considerably longer and gets rather farther afield.)

On 10/27/2014 at 11:54 PM, Russ Allbery wrote:

> The Wanderer  writes:
> 
>> Just as a note, one difference here is that there is support in
>> the archive and package-distribution mechanisms for having multiple
>> versions of a package for different architectures or (I think?)
>> kernels, so that you can build a version with some optional
>> features for one architecture / kernel but a version without those
>> optional features on another - but there is no such support for
>> having multiple versions of a package for different init systems.
> 
>> You can only have one architecture, only one kernel, and only one
>> init system active at any given time. The archive and its
>> infrastructure recognizes this for architectures and (I think)
>> kernels, and supports special handling for them to avoid or work
>> around problems which would (or easily could) otherwise be present.
>> The archive and its infrastructure do not presently recognize this
>> or provide such support for init systems; as such, no such
>> workarounds are available.
> 
> *looks at his packages that support systemd, upstart, and sysvinit*
> I think you're confused about where the hard parts of this process
> are.
> 
> It's often easier to support multiple init systems in a package than 
> supporting multiple architectures or multiple kernels.  It's
> certainly nothing that tremendously difficult to do.

What sort of packages are these, and what sort of support is involved?

What I'm thinking of is cases where upstream has decided to depend on
functionality that is provided by one init system but not by others,
without graceful runtime fallback - compile-time choices, essentially,
where functionality is omitted if the init system is not present. I have
had the impression that GNOME is one such upstream, to whatever extent
it has not dropped support for non-systemd environments entirely.

If adding support for other init systems to such packages (so that they
do not assume the presence of certain functionality in the environment,
but either can provide it themselves, or will simply fall back to not
providing certain features if that functionality is not present) is not
difficult, then that's certainly a good thing - but that is not the
impression I've gotten from the comments thus far.

My comments were pretty much not at all about init scripts or their
equivalents, which after all are only about starting or stopping
whatever "service" is in question, but only about functionality provided
to other processes by the running init system.

> The packages that are causing all the controversy at the moment
> aren't created by some sort of archive limitations, or even by a
> breakdown of this process.  The problem, rather, is that only one
> init system (or at least one init system's infrastructure; I'm
> counting logind as part of systemd here) supports some decidedly
> non-trivial features that those packages use, and no one has provided
> a supported implementation of those features for other init systems.
> In other words, they're very much akin to ZFS on FreeBSD.

And that's entirely my point: something which depends on a feature
provided by a kernel or an architecture, such that it won't build / run
properly on anything that doesn't provide that feature, can be packaged
either so as to be compiled with support for the feature in environments
which provide it and without support for it in environments which don't
or so as to be available (package visible to the package manager) in
environments where the feature is available and not in ones where it is
not - but something which depends on a feature provided by an init
system cannot AFAIK be packaged in a comparably varying way, with the
current packaging infrastructure.

I am sort-of attempting to propose a different model for expressing the
dependency of these upstreams (and the resulting packages) on the
functionality provided by one particular init system, one which might be
able to more easily allow "package with dependency and with matching
functionality" to coexist with "package without dependency and without
matching functionality".

> But we already have a reasonable workaround in the form of getting
> the systemd component to work under sysvinit.

That's a matter of providing the functionality under other init systems.
I am talking about making it (relatively) easy to provide parallel
versions of the package which work when the functionality is not
available in the environment, and/or making it possible for a package to
express its absolute dependence on the functionality in a way that does
not have such unfortunate failure states. The latter may be addressed by
systemd-shim (at least within environments which systemd i

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Russ Allbery]

The Wanderer  writes:

> Just as a note, one difference here is that there is support in the
> archive and package-distribution mechanisms for having multiple versions
> of a package for different architectures or (I think?) kernels, so that
> you can build a version with some optional features for one architecture
> / kernel but a version without those optional features on another - but
> there is no such support for having multiple versions of a package for
> different init systems.

> You can only have one architecture, only one kernel, and only one init
> system active at any given time. The archive and its infrastructure
> recognizes this for architectures and (I think) kernels, and supports
> special handling for them to avoid or work around problems which would
> (or easily could) otherwise be present. The archive and its
> infrastructure do not presently recognize this or provide such support
> for init systems; as such, no such workarounds are available.

*looks at his packages that support systemd, upstart, and sysvinit*  I
think you're confused about where the hard parts of this process are.

It's often easier to support multiple init systems in a package than
supporting multiple architectures or multiple kernels.  It's certainly
nothing that tremendously difficult to do.  The hard part isn't the
support; it's the testing, but we have that problem already with multiple
architectures.  I build and test my packages on amd64 and then upload them
and hope they work on, say, s390, but never look at an s390 system unless
something breaks.  There may be init scripts in my packages that I never
use, and therefore won't notice if they break, but the same thing is
already true of, say, the menu entries or the doc-base files.  Other
people who do use those things notice when they break and file bugs, or
incorporate good tests into Lintian that will tell me what to do, and I do
those things as part of maintaining my package.

This is routine stuff in Debian, or at least it was before people started
screaming and yelling at each other.  I expect I'm not the only person who
finds the screaming and yelling decidedly unmotivating, and who has cut
back on Debian work as a partial reaction, but that's hopefully a
temporary aberration in this way of working together.

There are a few maintainers who don't merge such things, and that tends to
provoke a lot of frustration and irritation, and usually (although not
always) it gets worked around or undone in some way.  Most people *want*
to merge changes that help other people do things they want to do with
their Debian systems, and it's rarely much of a contentious issue in
practice.  It usually only comes up when the maintainer and the patch
submitter disagree about how hard the support will be to maintain in the
long term.

The packages that are causing all the controversy at the moment aren't
created by some sort of archive limitations, or even by a breakdown of
this process.  The problem, rather, is that only one init system (or at
least one init system's infrastructure; I'm counting logind as part of
systemd here) supports some decidedly non-trivial features that those
packages use, and no one has provided a supported implementation of those
features for other init systems.  In other words, they're very much akin
to ZFS on FreeBSD.  But we already have a reasonable workaround in the
form of getting the systemd component to work under sysvinit.

> It seems possible that some of the problems potentially / arguably
> introduced by having features provided by only a subset of available
> init systems could be avoided or resolved by having multiple package
> versions for different init systems,

There's no reason to do that if someone is willing to port it.  You can
combine it all into one package trivially.  That's not the hard part; the
hard part is replacing the functionality that the package relies on but
which is only provided by one init system.  That's why people are putting
all that hard work into systemd-shim, which lets one use the systemd
logind component without running systemd itself.  Once that work is done,
then packages that rely on logind don't need to do anything particularly
special.

It's possible there will be more things like that going forward: upstream
packages that assume things like socket activation, for example.  And it's
quite possible to keep them working under other init systems using the
same sort of tactics: add socket activation to start-stop-daemon, or find
a way to use systemd under another init system to start the unit.  The
result probably won't be as efficient as systemd is, but that's typical
for porting, at least at first.

Or people could decide that they don't care enough to do the work, and
init systems that don't support socket activation could die a natural free
software death: they still exist, but not enough people use them to
maintain critical math.  That's not necessarily a bad thing.  I've been
working in free softwar

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[The Wanderer]

On 10/27/2014 at 10:29 PM, Anthony Towns wrote:

> On 28 October 2014 02:36, Steve Langasek  wrote:

>>> It's clear that many who support systemd balk at the idea they
>>> might not be allowed to leverage systemd-specific features in
>>> Debian.
> 
> I'm not sure I've seen people seriously proposing preventing people
> from leveraging systemd-specific features. Are they? That seems like
> a bad idea -- I wouldn't expect people to be forbidden from letting
> their packages take advantage of powerpc or freebsd specific
> features, just because I won't be able to use them on inux/amd64.

Just as a note, one difference here is that there is support in the
archive and package-distribution mechanisms for having multiple versions
of a package for different architectures or (I think?) kernels, so that
you can build a version with some optional features for one architecture
/ kernel but a version without those optional features on another - but
there is no such support for having multiple versions of a package for
different init systems.

You can only have one architecture, only one kernel, and only one init
system active at any given time. The archive and its infrastructure
recognizes this for architectures and (I think) kernels, and supports
special handling for them to avoid or work around problems which would
(or easily could) otherwise be present. The archive and its
infrastructure do not presently recognize this or provide such support
for init systems; as such, no such workarounds are available.

It seems possible that some of the problems potentially / arguably
introduced by having features provided by only a subset of available
init systems could be avoided or resolved by having multiple package
versions for different init systems, much as we already have for
different architectures and in some cases kernels. However, I'm not at
all sure that it's clear that the benefit of having such would be worth
the trouble of setting it up and maintaining it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Anthony Towns]

-project dropped -- no need to spam multiple lists, and -vote seems
like the right place for this topic to me.

On 28 October 2014 02:36, Steve Langasek  wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
>> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> > On 24 October 2014 13:15, Anthony Towns  wrote:
>> > > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
>> > >> No developer in that chain was compelled to run this under other init
>> > >> systems.
>> > > Well, yeah:
>> > > "1. Nothing in this constitution imposes an obligation on anyone to do
>> > > work for the Project."
>> > > Compelling developers isn't something that can be done in Debian.
>> > No, but we set up requirements that their work must meet before it can
>> > enter archive or may end up in a release.
>> Sure, but isn't that just /how/ you compel them?
>> If you were literally beating people with a stick for not testing their
>> packages with other init systems, that would certainly be compulsion, no?
>> Using policy and RC bugs as a metaphorical stick to beat people with
>> would similarly be compulsion, in my view.
> Debian never compels anyone to do any work.

[then later...]

> It is a form of compulsion that is legitimate under our constitution.  [...]

I don't think you can have it both ways -- either it's a legitimate
form of compulsion, and Debian does compel folks sometimes; or neither
of those things.

I guess the way I'd separate the two is that it's "legitimate" in that
it's not making someone do something, but rather preventing them from
doing something; and that it's "compulsion" in that it's only
preventing them from doing thing A, conditional on them also doing
thing B. And Debian does do that sometimes; though I'd argue that's
very limited -- and usually involves thing B being much less effort
than thing A, and usually directly benefiting everyone who cares about
A.

For instance, if you package "foo", you also have to deal with
security holes in "foo", or put its files in the usual places rather
than /opt or similar.

However if you package "foo" for Linux on amd64, you don't also have
to package it for ppc or freebsd -- you're encouraged to make it
"portable", so that someone else will build it for those
archictectures automatically, and you're expected to apply patches to
fix bugs if users report them, but that's about it.

> You can read this as compulsion if you want, but that's clearly not what the
> constitution means when it speaks of compulsion,

(The constitution doesn't speak of compulsion, it speaks of obligation)

What it says is "Nothing in this constitution imposes an obligation on
anyone to do work for the Project. A person who does not want to do a
task which has been delegated or assigned to them does not need to do
it."

That alone is actually sufficient for most RC bug policy:

 - package "foo" has a whole bunch of buffer overflows and tmp-file
bugs and other security things and would need a major rewrite to be
remotely secure
 - Alice packages foo, uploads it to unstable
 - it's automatically accepted to unstable
 - security conscious user/developer Bob files an RC bug, documenting
the security issues
 - Alice says people should just use it in trusted environments, and
doesn't have the time to try to fix it
 - release manager Carol ensures the package isn't included in the release

Results:

 - Alice does not need to fix the bug, despite being the maintainer of
the package
 - Carol does not need to include the package in the release

If she wanted to do the work, Alice could try creating her own release
with different policies to Carol's/Debian's of course. And Dave could
come along and actually fix the security holes (maybe working with
Alice to maintain the patches in Debian, maybe working with upstream,
maybe taking over maintenance of the package, maybe forking the
software under a different name).

The corresponding question for services versus init systems would be:

 - package "foo" has a .service file upstream, but no init script
 - Alice packages foo, doesn't write an init script, and uploads it to unstable
 - it's automatically accepted to unstable
 - upstart user Bob files a bug requesting an init script, but doesn't
provide a patch
 - Alice says "just use systemd" and still doesn't write an init script

with the question being "does release manager Carol stop the package
from being released"?

AIUI, policy hasn't ever made not having an init script an RC bug (ie,
it says "Packages that include daemons for system services should
place scripts in `/etc/init.d' to start or stop services at boot time
or during a change of runlevel.", rather than "must place"). So
currently, I would expect the answer to be that Carol wouldn't stop
the package from being released.

> because immediately after
> stating that no one is compelled to do any work for the project it goes on
> to say that they are not allowed to work against its rules.  And one o

Re: Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Uoti Urpala]

Steve Langasek wrote:
> On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
> > If you were literally beating people with a stick for not testing their
> > packages with other init systems, that would certainly be compulsion, no?
> > Using policy and RC bugs as a metaphorical stick to beat people with
> > would similarly be compulsion, in my view.
> 
> Debian never compels anyone to do any work.  They always have the option of
> not doing the work, and as a result, not having the software that they care
> about being included in the release.
> 
> You can read this as compulsion if you want, but that's clearly not what the
> constitution means when it speaks of compulsion, because immediately after
> stating that no one is compelled to do any work for the project it goes on
> to say that they are not allowed to work against its rules.  And one of
> those rules is that we can set technical policies for the project by a

But this GR has effects beyond anything that could be reasonably
described as a general technical policy. It prohibits even leaf packages
that offer functionality to the majority of people, unless the
maintainers do possibly significant work for the benefit of a certain
minority.

Would you consider it as purely technical policy if Debian tried to help
the adoption of better programming languages by forbidding any program
implemented in PHP unless there's an equivalent program implemented in
another language, or forbidding packaging of Perl modules unless an
equivalent module was available for Python?


> At the same time that systemd skeptics are feeling marginalized by the
> systemd decision, systemd supporters are concerned about being prevented
> from adopting systemd-specific interfaces that they want to use.  Well, only
> one of these groups can be a majority.  Either the majority of DDs want us
> to let software leverage systemd interfaces all the way up the stack,
> possibly breaking support for non-systemd init; or the majority of DDs want
> us to hold the line on diversity with respect to init systems, ensuring that
> new interfaces need to be negotiated with the project in some fashion before
> being adopted in the distribution; or both of these are minority views. 
> It's a legitimate use of the GR process to find out which of these groups is
> actually the majority, and to require the project to respect the will of
> that majority with regards to an issue that threatens to drive deep fissures
> through our archive and through our community.

IMO the above could be a valid justification for *a* GR, but it does not
really apply to *this* particular GR proposed by Ian. There is no clear
"leverage systemd interfaces all the way up the stack, possibly breaking
support for non-systemd init" option for systemd supporters to select.
The anti-systemd option is not "ensuring that new interfaces need to be
negotiated with the project in some fashion", but strictly sticking with
the obsolete sysvinit, no room for negotiating any upgrades.


> thing to do.  But I'm not even sure how I come down on this particular GR
> question yet *personally*, because even if I think we should adopt systemd,
> I have grave misgivings about Debian being tied to an upgrade treadmill by
> an upstream that may pay little heed to things that matter to Debian's
> community in the absence of a forcing function.

If you have concerns about the *future* development of systemd, is
sticking with sysvinit-level functionality like this GR really a sane
answer? Even if systemd development goes in a direction Debian does not
like, why wouldn't a fork of systemd be a better answer to that? It
shouldn't be too much work to maintain a fork if it's only required to
work better than sysvinit.


> There are very powerful network effects with PID 1.  I do not believe that a
> "do-ocracy" approach is sensible in the face of such monopoly potential. 
> The playing field will always be biased towards the option that bundles more
> features, whether or not Debian as a whole *wants* those features.  Leaving
> it for sysvinit supporters to play catch-up on features is not a way to
> decide this matter if Debian's majority doesn't believe it's appropriate to
> bundle those features in the first place.  (N.B.: this doesn't require

Systemd developers are making fast progress implementing several
positive features that are desirable for Debian too. It does not really
matter whether the majority believes it's appropriate to bundle those
features with each other (or with other features that people don't care
about) if there is no realistic plan to implement an at all comparable
level of functionality without such bundling. "Biased" playing field or
not, if one side gets a huge amount of useful functionality working and
the other has nothing, trying to declare the latter side a winner only
makes you ridiculous and/or irrelevant. And I don't believe that you
could get a large amount of sysvinit work done by "you must work on this
o

Legitimate exercise of our constitutional decision-making processes [Was, Re: Tentative summary of the amendments]

[Steve Langasek]

On Fri, Oct 24, 2014 at 01:32:36PM +, Anthony Towns wrote:
> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> > On 24 October 2014 13:15, Anthony Towns  wrote:
> > > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> > >> No developer in that chain was compelled to run this under other init
> > >> systems.
> > > Well, yeah:
> > > "1. Nothing in this constitution imposes an obligation on anyone to do
> > > work for the Project."
> > > Compelling developers isn't something that can be done in Debian.
> > No, but we set up requirements that their work must meet before it can
> > enter archive or may end up in a release. 

> Sure, but isn't that just /how/ you compel them? 

> If you were literally beating people with a stick for not testing their
> packages with other init systems, that would certainly be compulsion, no?
> Using policy and RC bugs as a metaphorical stick to beat people with
> would similarly be compulsion, in my view.

Debian never compels anyone to do any work.  They always have the option of
not doing the work, and as a result, not having the software that they care
about being included in the release.

You can read this as compulsion if you want, but that's clearly not what the
constitution means when it speaks of compulsion, because immediately after
stating that no one is compelled to do any work for the project it goes on
to say that they are not allowed to work against its rules.  And one of
those rules is that we can set technical policies for the project by a
series of increasingly heavyweight methods, up to and including a majority
vote by the full project.


This GR comes about because a large number of our developers and users who
have not been convinced that systemd is the right solution, or who believe
that it is not ready for Debian to adopt *yet* even if it is the right
solution over the long term, feel marginalized by the way systemd
integration is moving forward.  It's clear that many who support systemd
balk at the idea they might not be allowed to leverage systemd-specific
features in Debian.  But if the various imprecations about "encouraging"
ongoing support for alternate init systems are to be more than a fig leaf,
then this should be encoded in the policy - not left to a thousand
individual maintainers and upstream developers, some of whom will wind up
painting us into a corner.

Policy says today that packages should integrate with the init system using
/etc/init.d scripts.  The expectation is already there that packages will
remain compatible with the least-common denominator *init* interfaces for
now.  The real problem is when software integrates with a variety of
interfaces that are *not* traditionally part of init but are nevertheless
bundled with systemd.  It's entirely appropriate for Policy to say something
about how those interfaces may or may not be depended on in Debian.


At the same time that systemd skeptics are feeling marginalized by the
systemd decision, systemd supporters are concerned about being prevented
from adopting systemd-specific interfaces that they want to use.  Well, only
one of these groups can be a majority.  Either the majority of DDs want us
to let software leverage systemd interfaces all the way up the stack,
possibly breaking support for non-systemd init; or the majority of DDs want
us to hold the line on diversity with respect to init systems, ensuring that
new interfaces need to be negotiated with the project in some fashion before
being adopted in the distribution; or both of these are minority views. 
It's a legitimate use of the GR process to find out which of these groups is
actually the majority, and to require the project to respect the will of
that majority with regards to an issue that threatens to drive deep fissures
through our archive and through our community.

I don't know which side is in the majority.  We know that the TC was evenly
split on a choice of future default init system.  I don't think I can draw
any conclusions from that about what rules Debian wants about alternative
init systems.  I can say that systemd was my second choice (i.e., not my
last choice) as a member of the TC, and that in the aftermath of that vote I
believe moving forward with systemd as Debian's default init is the right
thing to do.  But I'm not even sure how I come down on this particular GR
question yet *personally*, because even if I think we should adopt systemd,
I have grave misgivings about Debian being tied to an upgrade treadmill by
an upstream that may pay little heed to things that matter to Debian's
community in the absence of a forcing function.

There are very powerful network effects with PID 1.  I do not believe that a
"do-ocracy" approach is sensible in the face of such monopoly potential. 
The playing field will always be biased towards the option that bundles more
features, whether or not Debian as a whole *wants* those features.  Leaving
it for sysvinit supporters to play catch-up on

Re: Tentative summary of the amendments

[Marco d'Itri]

On Oct 26, Flavius Bindea  wrote:

> if systemd is goinging to be the default I'll switch to another distrib.
systemd is already the default and it will still be the default no 
matter the outcome of this GR, which is about something else.

> maybe to a fork.
Cool. Debian encourages forks.

-- 
ciao,
Marco


signature.asc
Description: Digital signature

Re: Tentative summary of the amendments

[Flavius Bindea]

if systemd is goinging to be the default I'll switch to another distrib.
maybe to a fork.


2014-10-25 23:38 GMT+02:00 Marco d'Itri :

> svante.sign...@gmail.com wrote:
>
> >This is incredible, 90+ postings are from the pro systemd people. Are
> >you afraid of something? Where do the other side of view speak up. Seems
> Indeed, it looks like that systemd users are seriously underrepresented
> in these threads:
>
>
> https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1
>
> --
> ciao,
> Marco
>
>
> --
> To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive: https://lists.debian.org/m2h58b$191$1...@posted-at.bofh.it
>
>

Re: Tentative summary of the amendments

[Steve Langasek]

On Sat, Oct 25, 2014 at 11:52:32AM -0400, Miles Fidelman wrote:
> Olav Vitters wrote:

> >3. That we tried to blackmail someone

> if it looks like a duck, and quacks like a duck..

> >4. That it is about sysvinit scripts

> Again, of course it is.

> >If you cannot, it seems you just performed libel. Suggest to be very
> >careful in the claims you make. Actually, I suggest you to cease and
> >desist.

> "if you think my statement is libelous, go ahead and sue - I'd LOVE to have
> the behavior of those behind systemd to be more visibile."

This is absolutely inappropriate and off-topic for this list.  Neither you
nor Olav have voting rights in Debian.  Even if this were somehow an
acceptable way for you to go about persuading Debian's voters, which it's
not, you're not doing that - you're just addressing yourself abusively to
someone else who is not a voter.

Please stop.

-- 
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: Tentative summary of the amendments

[Marco d'Itri]

svante.sign...@gmail.com wrote:

>This is incredible, 90+ postings are from the pro systemd people. Are
>you afraid of something? Where do the other side of view speak up. Seems
Indeed, it looks like that systemd users are seriously underrepresented
in these threads:

https://qa.debian.org/popcon-graph.php?packages=systemd-sysv+upstart+openrc+sysvinit-core+systemd-shim&show_installed=on&want_legend=on&want_ticks=on&from_date=2014-01-01&to_date=&hlght_date=&date_fmt=%25Y-%25m&beenhere=1

-- 
ciao,
Marco


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/m2h58b$191$1...@posted-at.bofh.it

Re: Tentative summary of the amendments

[Miles Fidelman]

Svante Signell wrote:

Hi,

This is incredible, 90+ postings are from the pro systemd people. Are
you afraid of something? Where do the other side of view speak up. Seems
like the same thing happening again when the default init system was
chosen, the more loudly the more strength in affecting peoples opinions.
Keep on, and you will win again :-(



Actually, all the anti-systemd voices seem to be on lists related to 
network operations.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544bf6fb.4020...@meetinghouse.net

Re: Tentative summary of the amendments

[Svante Signell]

Hi,

This is incredible, 90+ postings are from the pro systemd people. Are
you afraid of something? Where do the other side of view speak up. Seems
like the same thing happening again when the default init system was
chosen, the more loudly the more strength in affecting peoples opinions.
Keep on, and you will win again :-(


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414262802.4095.5.ca...@gmail.com

Re: Tentative summary of the amendments

[Miles Fidelman]

Olav Vitters wrote:

On Fri, Oct 24, 2014 at 09:56:33AM -0400, Miles Fidelman wrote:

All this talk about what upstream developers will and won't do.
Seems to me that they've been writing sysvinit scripts for years;
systemd support ADDS work.  It's only the GNOME developers who are
being rather vocal about not supporting sysvinit, to the extent of
IMHO blackmail.

Can you back this up?

So:
1. *Only* the GNOME developers


Well... so far, for all the major software I use (mysql, postgresql, 
postfix, ...) and some that I've been considering (notably sheepdog), 
the discussions used to be along the lines of 'oh sh*t, we need to write 
systemd init scripts' as opposed to 'you need to run systemd to use 
.

2. That's it is about sysvinit

of course it's about sysvinit - what other, mature init system is there?


3. That we tried to blackmail someone


if it looks like a duck, and quacks like a duck..


4. That it is about sysvinit scripts


Again, of course it is.


If you cannot, it seems you just performed libel. Suggest to be very
careful in the claims you make. Actually, I suggest you to cease and
desist.


"if you think my statement is libelous, go ahead and sue - I'd LOVE to 
have the behavior of those behind systemd to be more visibile."



I've been communicating on debian-devel for a very long time. It seems
you missed everything and just make simple minded assumptions. It is ok
to be simple minded and utterly wrong. What is wrong is then to turn
that into calls of "blackmail".

You're so far off it's not funny.


You're just laughable.

Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544bc740.6000...@meetinghouse.net

Re: Tentative summary of the amendments

[Josh Triplett]

On Sat, Oct 25, 2014 at 03:21:51PM +0200, Jonas Smedegaard wrote:
> Quoting Josh Triplett (2014-10-25 11:52:28)
> > Jonas Smedegaard wrote:
> >> Quoting Josh Triplett (2014-10-24 16:27:27)
> >>> Aigars Mahinovs wrote:
>  On 24 October 2014 13:33, Ansgar Burchardt  
>  wrote:
> > I don't like some software too, but am sometimes required to use 
> > it without an alternative. Can I demand that I can use packages 
> > without said software? Like demanding libraries having to provide 
> > language bindings for at least two languages so I don't have to 
> > use PHP[1]? :)
>  Init system is special because there can be only one active in the 
>  system. If app1 depends on systemd (as PID 1) and app2 depends on 
>  runit (as PID 1) then it becomes impossible to use both apps 
>  (without changing init system and rebooting). Also IMHO init system 
>  should be a user choice and not dictated by other, unrelated, 
>  software.
> >>>
> >>> Kernels are special because there can be only one active in the 
> >>> system. If app1 depends on Linux and app2 depends on FreeBSD, then 
> >>> it becomes impossible to use both apps (without changing kernels and 
> >>> rebooting).
> >>
> >> Can you provide any concrete examples of that actually being an 
> >> issue?
> >
> > Yes, in both directions.
> >
> > For the more common "depends on Linux" case: portions of FUSE 
> > (partially addressed by a FUSE port for BSD, but not all filesystems 
> > work with that), ALSA (and indirectly anything using it for sound), 
> > BlueZ (Bluetooth support), more recent inotify-like interfaces, many 
> > networking and wireless tools, cell modem support, many filesystem 
> > tools, various hardware access libraries, some backup tools, some 
> > build tools, systemd and systemd-shim, and until not too long ago 
> > sysvinit. (That's only the software that *explicitly* only runs on 
> > Linux, as opposed to software which says "any" but doesn't build or 
> > run on FreeBSD, which I'd assume applies to a non-zero number of 
> > packages.)
> > 
> > For the fairly rare (at least in Debian) "depends on FreeBSD" case, I 
> > only know one example off the top of my head: ZFS (since Linux only 
> > has the low-performance zfs-fuse).
> 
> I meant examples not only of arch-constraints, but of arch-constraints 
> being an *issue*.  Seems you provide only the former above.
> 
> Existence of arch-constraints is analogous to existence of init systems 
> with different ABI.  What we are talking about here is issues it causes 
> - whether those are mostly theoretical or actually occuring in Debian, 
> and whether they are treated as problems for package maintainers to deal 
> with (Policy "forcing maintainers to do "extra work" as some put it) or 
> not.

Any missing functionality or packages on kernel or architecture A
compared to B certainly is an issue for the people wanting to run A, and
presumably the users, developers, and maintainers of A would like to see
more packages and more functionality run on A.  Policy certainly doesn't
force package maintainers to do extra work in this case, because it
places no hard requirements on architecture support.  Porters write
patches, and as I understand it the FreeBSD architecture maintainers do
spend a significant amount of time making things work on FreeBSD and
removing Linux-specific assumptions from code.  FreeBSD developers
upstream also work to provide kernel functionality to help support a
broader range of software (e.g. linprocfs).

Beyond that, I don't see what distinction you're drawing by about this
being or not being an "issue".  As mentioned below, the world certainly
hasn't ended over it.  Likewise, I don't know of any current "issues"
caused by init-system-specific software that haven't already been fixed,
and the world hasn't ended over that either.

For architectures, kernels, *and* init systems, I personally agree with
Charles' statement that "the procedures for decision making and conflict
resolution are working adequately and thus a General Resolution is not
required."  Though for the purposes of curtailing further FUD and
doomsaying, I'd personally rank Lucas's and Luca's statements higher.

> > So, in a situation rather analogous to the init systems: Linux runs 
> > just about everything, FreeBSD runs most things but has little that 
> > specifically depends on it.  Which makes this a fairly small problem 
> > for Linux users, and a noticeable lack if you want to run FreeBSD.  
> > However, the FreeBSD folks have done an impressive job keeping up, and 
> > many packages have been willing to add FreeBSD support.
> 
> Phrasing it as "have been willing" make it sound like optional work.  

Since it *is* optional, I intentionally phrased it as such.  And to be
clear, the specific work I had in mind was that some package maintainers
have gone out of their way to make their packages work on FreeBSD rather
than just waiting for patches, even though they

Re: Tentative summary of the amendments

[Matthias Urlichs]

Hi,

j...@joshtriplett.org:
> Personally, I'd actually love to see a port of systemd (a *complete*
> port of systemd) to be capable of running in system mode without being
> PID 1.

Why would you need to port it?
You can do that today quite easily; just say "systemd --system".

I have no idea what that does WRT cgroups management, and obviously it
won't be able to cleanly shut down the system, but AFAIK everything else
should work.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141025143437.gh4...@smurf.noris.de

Re: Tentative summary of the amendments

[Matthias Urlichs]

Hi,

Josh Triplett:
> There's a reason that systemd has had a meteoric adoption rate: it
> provides a huge number of features people not only want, but have wanted
> for years.
> 
Or didn't even know they wanted. Or simply didn't have *time* to implement
a workaround for. The integrated logging which "systemctl status" prints
is a prime example.

Yes, there have been a number of replacement inits, but every one of them
just scratched an itch or two, so the perceived benefit to switching to it
was too small. None of them ever tried to take away _all_ the itchy
scratchy bits.

> In practice, demanding that packages work with all init systems, or even
> with *two* init systems, demands that they support the
> least-common-denominator of functionality provided by those init
> systems.  That effectively makes any new feature added to an init system
> useless until duplicated.
> 
Not always. Take socket activation, for instance. It's reasonably easy to
implement, and simply a no-op on any non-systemd machine.

> And in many cases, the systemd-invented services and features fill a gap
> for which no previously implementation existed, so "used to work before"
> is quite inaccurate.

Many daemons have implemented painful workarounds. (Painful because they
come with their own set of bugs … and implementing them anew in every
daemon that needs the features is wasted effort.)

A quick look at my system:
* collectd has a restarter (C)
* asterisk has a watchdog (C)
* mysqld has a logger (C) and a restarter (shell)
* rabbitmq has an uid-setter (shell, calling 'su -c "…"',
  with broken quoting)

I expect their (eventual) unit files to do away with all of that.

-- 
-- Matthias Urlichs


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141025140455.gg4...@smurf.noris.de

Re: Tentative summary of the amendments

[Jonas Smedegaard]

Quoting Josh Triplett (2014-10-25 11:52:28)
> [Please CC me on replies; I'm not subscribed to -vote, so for mails not
> CCed to me, I end up responding via the archives and manually quoting
> via copy/paste.]
>
> Jonas Smedegaard wrote:
>> Quoting Josh Triplett (2014-10-24 16:27:27)
>>> Aigars Mahinovs wrote:
 On 24 October 2014 13:33, Ansgar Burchardt  
 wrote:
> I don't like some software too, but am sometimes required to use 
> it without an alternative. Can I demand that I can use packages 
> without said software? Like demanding libraries having to provide 
> language bindings for at least two languages so I don't have to 
> use PHP[1]? :)
 Init system is special because there can be only one active in the 
 system. If app1 depends on systemd (as PID 1) and app2 depends on 
 runit (as PID 1) then it becomes impossible to use both apps 
 (without changing init system and rebooting). Also IMHO init system 
 should be a user choice and not dictated by other, unrelated, 
 software.
>>>
>>> Kernels are special because there can be only one active in the 
>>> system. If app1 depends on Linux and app2 depends on FreeBSD, then 
>>> it becomes impossible to use both apps (without changing kernels and 
>>> rebooting).
>>
>> Can you provide any concrete examples of that actually being an 
>> issue?
>
> Yes, in both directions.
>
> For the more common "depends on Linux" case: portions of FUSE 
> (partially addressed by a FUSE port for BSD, but not all filesystems 
> work with that), ALSA (and indirectly anything using it for sound), 
> BlueZ (Bluetooth support), more recent inotify-like interfaces, many 
> networking and wireless tools, cell modem support, many filesystem 
> tools, various hardware access libraries, some backup tools, some 
> build tools, systemd and systemd-shim, and until not too long ago 
> sysvinit. (That's only the software that *explicitly* only runs on 
> Linux, as opposed to software which says "any" but doesn't build or 
> run on FreeBSD, which I'd assume applies to a non-zero number of 
> packages.)
> 
> For the fairly rare (at least in Debian) "depends on FreeBSD" case, I 
> only know one example off the top of my head: ZFS (since Linux only 
> has the low-performance zfs-fuse).

I meant examples not only of arch-constraints, but of arch-constraints 
being an *issue*.  Seems you provide only the former above.

Existence of arch-constraints is analogous to existence of init systems 
with different ABI.  What we are talking about here is issues it causes 
- whether those are mostly theoretical or actually occuring in Debian, 
and whether they are treated as problems for package maintainers to deal 
with (Policy "forcing maintainers to do "extra work" as some put it) or 
not.


> So, in a situation rather analogous to the init systems: Linux runs 
> just about everything, FreeBSD runs most things but has little that 
> specifically depends on it.  Which makes this a fairly small problem 
> for Linux users, and a noticeable lack if you want to run FreeBSD.  
> However, the FreeBSD folks have done an impressive job keeping up, and 
> many packages have been willing to add FreeBSD support.

Phrasing it as "have been willing" make it sound like optional work.  
Sure, in the end *all* work on Debian is volunteer, so even a "must" in 
Policy is something "packages have been willing to [...] support".


>>> And yet we don't stop applications from declaring "Architecture: 
>>> linux-any".  And the world has not ended.  People who maintain 
>>> non-Linux kernels have a substantial amount of work to do, and I 
>>> find it very impressive how much they've gotten working.  Yet nobody 
>>> has proposed a GR forcing support for kFreeBSD or the Hurd; the 
>>> people working on them have simply *done the work*, and in some 
>>> cases successfully convinced others to do the same.
>>
>> We do strongly discourage that, as codified in Debian Policy §5.6.8:
>>
>>> Specifying a list of architectures or architecture wildcards other 
>>> than `any' is for the minority of cases where a program is not 
>>> portable or is not useful on some architectures.  Where possible, 
>>> the program should be made portable instead.
>>
>> Notice the "should" near the end of above.
>
> Notice as well that it doesn't say "must".

A "should" regarding covering all, not describing coverage of some.


> We've already had TC decisions that explicitly gave the equivalent of 
> a "should";

That was my impression too, when I read the announcement from the TC.

It is *not* my impression that it has since been treated as a should.


> this GR would effectively enforce a "must", making it RC to depend on 
> an init system.  The equivalent would be making it RC to not support 
> all architectures.

A "must" regarding "more than one", not describing coverage of all.

No, it is equivalent of supporting _more_than_one_ architecture - where 
an equivalent of "do uselessd count?" would be "do

Re: Tentative summary of the amendments

[Josselin Mouette]

Le vendredi 24 octobre 2014 à 14:47 +0200, Josselin Mouette a écrit :
> There
> have been, are and will be people with different requirements that
> systemd does not and will not satisfy.
> 
> Which requirements are not satisfied by systemd? I’m pretty sure the
> upstream systemd developers would be willing to do what’s necessary to
> satisfy those users. 

Aigars, unless you answer this question, I’ll have to assume you are not
interested in a constructive discussion.

And I’ll add to that the fact you have been assuming bad faith, and have
still not apologized for doing so.

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


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/1414240702.19411.3.ca...@kagura.malsain.org

Re: Tentative summary of the amendments

[Olav Vitters]

On Fri, Oct 24, 2014 at 09:56:33AM -0400, Miles Fidelman wrote:
> All this talk about what upstream developers will and won't do.
> Seems to me that they've been writing sysvinit scripts for years;
> systemd support ADDS work.  It's only the GNOME developers who are
> being rather vocal about not supporting sysvinit, to the extent of
> IMHO blackmail.

Can you back this up?

So:
1. *Only* the GNOME developers
2. That's it is about sysvinit
3. That we tried to blackmail someone
4. That it is about sysvinit scripts

If you cannot, it seems you just performed libel. Suggest to be very
careful in the claims you make. Actually, I suggest you to cease and
desist.

I've been communicating on debian-devel for a very long time. It seems
you missed everything and just make simple minded assumptions. It is ok
to be simple minded and utterly wrong. What is wrong is then to turn
that into calls of "blackmail".

You're so far off it's not funny.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141025115939.gd32...@bkor.dhs.org

Re: Tentative summary of the amendments

[Josh Triplett]

On Sat, Oct 25, 2014 at 12:51:04AM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 23:16,   wrote:
> > I'd personally be interested in your non-devil's-advocate reasons for 
> > caring, because
> > those seem likely to be solvable.
> 
> I, personally, love the init part of systemd - the part that starts
> services (either on startup or on events).
> 
> >> and there is no
> >> need to hardlock them into the init system too.
> >
> > I really wish you'd stop asserting this.  You, and others, would
> > *prefer* that they're not part of the init system.  That opinion (and it
> > is an opinion) on design and architecture is not universal, and there
> > are quite a few documented and frequently reiterated reasons to
> > integrate such features into an init system.
> 
> Let me rephrase that - my opinion is that it would have been almost as
> easy to design and implement the IPC parts of systemd in such a way
> that they could be used independently from the init system part. In a
> way where users could mix and match the parts that they want to use in
> a particular system. I know of ability to compile out some parts, as
> far as I understand that still does not allow to, for example, run
> logind from a bash shell. And, from what I hear, it is highly unlikely
> that patches to that effect would be accepted upstream.

Have you looked at the IPC interfaces of systemd, such as
org.freedesktop.systemd1?  Take a look at
http://www.freedesktop.org/wiki/Software/systemd/dbus/ , and reconsider
that opinion on ease of separate implementation.  The primary .Manager
interface provides detailed access to and control of units, jobs, system
state, systemwide environment, and transient unit launching; none of
that makes any sense to handle outside of systemd.   The same goes for
all of the other DBus interfaces, such as the scope/slice/cgroup/etc
interfaces used to dynamically set up and manage process groups at
runtime; on a systemd system, not one of those interfaces makes sense to
implement outside of systemd, because they're specifically about
constructing, controlling, and monitoring groups of processes, which on
a systemd system is systemd's job.

To use logind as an example service, because it's both the most widely
desired service *and* one of those most closely tied to systemd: logind
is specifically designed around cgroups and process/session supervision,
as an inherent part of handling seats, sessions, and user permissions.
Thus, logind uses scopes, slices, and various other interfaces, via the
systemd dbus interfaces.

systemd-shim implements versions of the interfaces needed to support
systemd services outside of systemd.  Some of those interfaces are
stubs, such as mocked-up unit properties for specific units that would
exist on a systemd system, and others are fairly simple
(shutdown/hibernate).  However, the scope/slice/etc handling is
non-trivial, and built upon cgmanager.  I certainly would not put down
the work of the systemd-shim developers and maintainers by suggesting
that doing so was *easy* to implement outside of systemd; it's hard
enough to implement *inside* of systemd.

(The paragraph above should be taken with a grain of salt, as I'm not an
expert on the internals of systemd-shim.)

In any case, I don't think it's reasonable to take the existence of
systemd-shim as an argument that the interface could have been designed
for use independently of the init system, at least not with the same
capabilities.  systemd-shim doesn't actually provide most of systemd's
functionality; it just provides a shim that lets logind run.

As an analogous situation (derived from the branch of this thread that's
discussing the analogy to kernels and architectures): I don't think it's
reasonable to take the existence of the Linux IIO ("Industrial I/O") and
FUSE ("Filesystem in Userspace") frameworks as arguments that the
majority of device or filesystem drivers should be written outside the
kernel.

> > On the contrary, you gain a great deal of flexibility, without having to
> > write any extra support for it.  Want to run another instance on another
> > port?  Add another .socket unit.  And note that you can do so in a
> > systemd --user instance if you want, or ephemerally via systemd-run or
> > systemd-activate.  Easy to start a debug version that way too.
> 
> We need to do a lot of work on updating Debian Policy and Debian
> Reference.

Working on that, along with many other people. :)

> I am learning new features of systemd with every week of
> these discussions.

:)

That's one of the reasons I prefer to have discussions about more
concrete questions and concerns, rather than abstract, theoretical, or
hypothetical issues.  Concrete questions and concerns have concrete
answers.

> I still don't like the tightly integrated design,
> but that in itself is just an irrelelvant opinion.

There are people who still dislike Linux for not being a microkernel. :)

And I wouldn't call your opinion *irrelevant*.  It's a vali

Re: Tentative summary of the amendments

[Josh Triplett]

[Please CC me on replies; I'm not subscribed to -vote, so for mails not
CCed to me, I end up responding via the archives and manually quoting
via copy/paste.]

Jonas Smedegaard wrote:
> Quoting Josh Triplett (2014-10-24 16:27:27)
> > Aigars Mahinovs wrote:
> >> On 24 October 2014 13:33, Ansgar Burchardt  wrote:
> >>> I don't like some software too, but am sometimes required to use it 
> >>> without an alternative. Can I demand that I can use packages without 
> >>> said software? Like demanding libraries having to provide language 
> >>> bindings for at least two languages so I don't have to use PHP[1]? 
> >>> :)
> >> Init system is special because there can be only one active in the 
> >> system. If app1 depends on systemd (as PID 1) and app2 depends on 
> >> runit (as PID 1) then it becomes impossible to use both apps (without 
> >> changing init system and rebooting). Also IMHO init system should be 
> >> a user choice and not dictated by other, unrelated, software.
> >
> > Kernels are special because there can be only one active in the 
> > system. If app1 depends on Linux and app2 depends on FreeBSD, then it 
> > becomes impossible to use both apps (without changing kernels and 
> > rebooting).
> 
> Can you provide any concrete examples of that actually being an issue?

Yes, in both directions.

For the more common "depends on Linux" case: portions of FUSE (partially
addressed by a FUSE port for BSD, but not all filesystems work with
that), ALSA (and indirectly anything using it for sound), BlueZ
(Bluetooth support), more recent inotify-like interfaces, many
networking and wireless tools, cell modem support, many filesystem
tools, various hardware access libraries, some backup tools, some build
tools, systemd and systemd-shim, and until not too long ago sysvinit.
(That's only the software that *explicitly* only runs on Linux, as
opposed to software which says "any" but doesn't build or run on
FreeBSD, which I'd assume applies to a non-zero number of packages.)

For the fairly rare (at least in Debian) "depends on FreeBSD" case, I
only know one example off the top of my head: ZFS (since Linux only has
the low-performance zfs-fuse).

So, in a situation rather analogous to the init systems: Linux runs just
about everything, FreeBSD runs most things but has little that
specifically depends on it.  Which makes this a fairly small problem for
Linux users, and a noticeable lack if you want to run FreeBSD.  However,
the FreeBSD folks have done an impressive job keeping up, and many
packages have been willing to add FreeBSD support.

(Processor architectures have a similar situation, most notably with
packages that generate code and the packages that build-depend on
those.)

> Reason for this GR is concrete examples (thankfully believed solved by 
> now) of it actually being an issue regarding init systems.

I have no reason to believe that the situation with init systems is
drastically different than those for kernels or for architectures.  In
both cases, I think the right answer is for package maintainers to
declare appropriate dependencies to reflect reality, for upstreams to
consider carefully the tradeoffs of portability, and for port / init
system supporters to continue writing and submitting patches or
developing alternatives.  Neither case justifies a GR or a policy
"must".

> > And yet we don't stop applications from declaring "Architecture: 
> > linux-any".  And the world has not ended.  People who maintain 
> > non-Linux kernels have a substantial amount of work to do, and I find 
> > it very impressive how much they've gotten working.  Yet nobody has 
> > proposed a GR forcing support for kFreeBSD or the Hurd; the people 
> > working on them have simply *done the work*, and in some cases 
> > successfully convinced others to do the same.
> 
> We do strongly discourage that, as codified in Debian Policy §5.6.8:
> 
> > Specifying a list of architectures or architecture wildcards other 
> > than `any' is for the minority of cases where a program is not 
> > portable or is not useful on some architectures.  Where possible, the 
> > program should be made portable instead.
> 
> Notice the "should" near the end of above.

Notice as well that it doesn't say "must".  We've already had TC
decisions that explicitly gave the equivalent of a "should"; this GR
would effectively enforce a "must", making it RC to depend on an init
system.  The equivalent would be making it RC to not support all
architectures.  And while portability can potentially be a desirable
feature, that doesn't make it RC to build architecture-specific
software.

If the GR had language like this:

"Depending on one or more specific init systems is for cases where a
program is not portable across all init systems or not useful under
other init systems.  Where possible, the program should be made portable
instead."

then I wouldn't be arguing against it, other than that a GR would be
overkill compared to proposing that via the Policy process 

Re: Tentative summary of the amendments

[Aigars Mahinovs]

On 24 October 2014 23:16,   wrote:
> I'd personally be interested in your non-devil's-advocate reasons for caring, 
> because
> those seem likely to be solvable.

I, personally, love the init part of systemd - the part that starts
services (either on startup or on events).

>> and there is no
>> need to hardlock them into the init system too.
>
> I really wish you'd stop asserting this.  You, and others, would
> *prefer* that they're not part of the init system.  That opinion (and it
> is an opinion) on design and architecture is not universal, and there
> are quite a few documented and frequently reiterated reasons to
> integrate such features into an init system.

Let me rephrase that - my opinion is that it would have been almost as
easy to design and implement the IPC parts of systemd in such a way
that they could be used independently from the init system part. In a
way where users could mix and match the parts that they want to use in
a particular system. I know of ability to compile out some parts, as
far as I understand that still does not allow to, for example, run
logind from a bash shell. And, from what I hear, it is highly unlikely
that patches to that effect would be accepted upstream.

> On the contrary, you gain a great deal of flexibility, without having to
> write any extra support for it.  Want to run another instance on another
> port?  Add another .socket unit.  And note that you can do so in a
> systemd --user instance if you want, or ephemerally via systemd-run or
> systemd-activate.  Easy to start a debug version that way too.

We need to do a lot of work on updating Debian Policy and Debian
Reference. I am learning new features of systemd with every week of
these discussions. I still don't like the tightly integrated design,
but that in itself is just an irrelelvant opinion.

>> Applications have never
>> been calling init system before. Try the same assumption with: bash,
>> Metacity, gnome-shell. "When you application is started, it might be
>> started by gnome-shell, in that case you may give gnome-shell an
>> indication about your startup animation, but you may be started by
>> something else, in that case you should still start, but it is fine
>> not to provide the correct startup animation."
>
> Talking about "startup animation" dismisses features and integration as
> trivial frivolities.  Since you mentioned gnome-shell and metacity,
> let's talk about an analogous situation to the systemd case.  Formerly,
> in GNOME 2, you could run a "panel applet" on top of gnome-panel, and
> run gnome-panel within any desktop environment and window manager you
> liked.  Neither gnome-panel nor those applets exist in GNOME 3

Even though those were clearly understood to be plugins of the panel
and not actual applications, there was quite passionate discussion
about both porting them to Gnome 3 and about making a freedesktop.org
common ground specification. Basically system notification area came
out of that as far as I rememeber.

> I think your analogy paints an unrealistically nostalgic and idyllic
> picture of life before systemd, as though there were a pile of equally
> capable init systems sitting around and a pile of software that all
> happily ran on all of them, until systemd came along and made everyone's
> life miserable by being entirely too useful.

Sounds about right.

> You're also implying that, out of a clear blue sky, the TC would declare
> a new default, as though they weren't asked specifically to decide an
> already contentious issue caused by a huge number of people *wanting* to
> support a new init system and being FUDded away from doing so.

Actually I am suggesting that TC would make a trivial decision on what
is to be the *default* architecture, while other people would choose
to understand that this decision means that all other architectures no
longer matter.

> Finally, you're suggesting that code already exists that would be
> "cleaned up" and removed, and assuming that's the only reason to limit
> architecture (or init system) support.  The common case here, however,
> would be *new* code to implement some new feature, depending on some new
> support provided by (for instance) a new service.

That is exactly what I am suggesting - the reason for the clean up
would be to reduce maintenance burden and add new features by using
features easily available on the default architecture (both perfectly
fine reasons), but the side effect is loss of support for other
architectures (which is no longer considered to be important by the
upstream or maintainers).
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--

Re: Tentative summary of the amendments

[Nikolaus Rath]

Ian Jackson  writes:
d> Jonas Smedegaard writes ("Re: Tentative summary of the amendments"):
>> Quoting Nikolaus Rath (2014-10-22 05:09:18)
>> > I believe Ian's intended reading is that a package that depends on 
>> > uselessd | systemd (but does not work with sysvinit) would be allowed 
>> > by his proposal.
>
> Yes.
>
> In practice such packages are not going to be a big problem because
> writing init scripts for them would be straightforward, and then the
> dependency could be relaxed.

I think this illustrates that the consequences of your proposal are
rather unclear.

* What if no-one does the work, even if it's straightforward? Is the
  package still allowed in Debian?

* What if the work isn't as straightforward as you expect?

* What if uselessd in the future adds additional features from systemd?
  Does this mean that at some point there might be "too many" features,
  so that depending on systemd|uselessd is considered just one init
  system?

* What if uselessd becomes dead upstream, or no longer packaged in
  Debian (e.g. because everyone uses either systemd or sysvinit)? Will
  this make all packages depending on it or systemd insta-buggy?


I understand that the main idea behind the GR is to send a clear message
to upstreams that Debian cares about the user being able to choose
different init systems. But I think framing this in the context of a
technical requirement on Debian packages is not a good idea.

Have you considered a proposal of the form "The Debian project considers
it very important to be able to run the system with multiple init
systems, and strongly urges upstream developers to support this"? I
think this would be much more likely to find a majority, and I don't
think it will be any less effective in convincing upstreams.


Best,
-Nikolaus
-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87a94lp4z3@rath.org

Re: Tentative summary of the amendments

[josh]

On Fri, Oct 24, 2014 at 08:31:22PM +0300, Aigars Mahinovs wrote:
> First of all, Josh, thank you for the long and reasoned replies. I do
> hope this back-and-forth is useful for others as well in the context
> of this decision, that is why I am still keeping the debian-vote list
> in the CC.

Likewise.

> On 24 October 2014 19:18, Josh Triplett  wrote:
> > Aigars Mahinovs wrote:
> >> Forget about init scripts. Imagine booting up a system with
> >> "init=/bin/sh" - it should be possible to run a command to start your
> >> service from there (without any init system at all). If you depend on
> >> other services, then those should be startable with simple commands
> >> too. If that is possible, then all is fine.
> >
> > More seriously, no, your expectations are no longer realistic or
> > reasonable.  It is already not possible *today* to run "simple commands"
> > and end up with a working system; many services depend on other running
> > services, and the thing gluing them together is an init system.
> 
> I am assuming that the person running the commands know about the
> dependencies in the services and starts them up manually and in the
> right order. Init system does *not* glue services together it only
> starts them in right order with right options - after that init system
> does not participate in the inter-process communication.

sysvinit doesn't, but then sysvinit knows very few ways to glue services
together.  Other init systems (not just systemd) do in fact do more than
just starting services in the right order with the right options, and do
potentially participate in inter-process communication.

> > It's perfectly reasonable, for instance, for a daemon to expect to be
> > run as a non-root user, and be handed a low-numbered socket that it
> > could not itself open.  It's not reasonable to require every daemon to
> > reimplement that code itself, with all associated security requirements.
> 
> That is what tools like start-stop-daemon or daemontools are for.
> There is no need to reinvent things for every daemon

Feel free to add more features to start-stop-daemon or daemontools, and
convince people to use them.  Bonus if you do so with a compatible
interface to make it easier to convince people (for instance, passing
the same environment variables to daemons).  To the best of my
knowledge, those tools don't currently support socket activation, nor
equivalents for 90+% of the directives in systemd.exec(5),
systemd.socket(5), and so on.  (If you haven't read those manpages
recently, consider doing so, to get an idea of the number and variety of
such features.)  There are some other tools that support other subsets,
such as minijail for security sandboxing features.  So you could
probably assemble an array of substitutes for a decent subset of systemd
unit functionality, along with documentation for how to correctly use
them in combination (often non-trivial if they don't live in the same
tool).  Nobody has done so yet.

Personally, I'd actually love to see a port of systemd (a *complete*
port of systemd) to be capable of running in system mode without being
PID 1.  I don't think that's something systemd upstream will accept
patches for, but it might be a maintainable patch as part of a
downstream fork.  While that certainly wouldn't make all systemd
opponents happy, it seems like that'd address your primary objection,
simply by making it possible to run systemd under sysvinit to launch and
manage systemd services. :)  That would also have the major advantage of
not making *anyone* do duplicate work.

It might help to know that one of the motivations that *started* me down
the path towards FOSS was realizing how much needless duplication
occurred in the proprietary software world purely through lack of code
sharing.  If someone *intentionally* wants to reinvent the wheel, fine,
and they might even manage to make a rounder wheel in the process.
However, I consider it completely unreasonable to *require* duplication
of implementation effort before using a new feature; that's a needless
waste of many people's time.

And I suspect, or at least hope, that you consider that unreasonable as
well.  It seems to me that your objections lie more with not wanting to
use systemd as PID 1 yet wanting to run other software.  I'd personally
be interested in your non-devil's-advocate reasons for caring, because
those seem likely to be solvable.

> and there is no
> need to hardlock them into the init system too.

I really wish you'd stop asserting this.  You, and others, would
*prefer* that they're not part of the init system.  That opinion (and it
is an opinion) on design and architecture is not universal, and there
are quite a few documented and frequently reiterated reasons to
integrate such features into an init system.  You may disagree with
those reasons, or with the relative weight given to them compared to
others you care more about; that does not invalidate them.  Other people
have legitimate technical requi

Re: Tentative summary of the amendments

[Jonas Smedegaard]

Quoting Josh Triplett (2014-10-24 16:27:27)
> Aigars Mahinovs wrote:
>> On 24 October 2014 13:33, Ansgar Burchardt  wrote:
>>> I don't like some software too, but am sometimes required to use it 
>>> without an alternative. Can I demand that I can use packages without 
>>> said software? Like demanding libraries having to provide language 
>>> bindings for at least two languages so I don't have to use PHP[1]? 
>>> :)
>> Init system is special because there can be only one active in the 
>> system. If app1 depends on systemd (as PID 1) and app2 depends on 
>> runit (as PID 1) then it becomes impossible to use both apps (without 
>> changing init system and rebooting). Also IMHO init system should be 
>> a user choice and not dictated by other, unrelated, software.
>
> Kernels are special because there can be only one active in the 
> system. If app1 depends on Linux and app2 depends on FreeBSD, then it 
> becomes impossible to use both apps (without changing kernels and 
> rebooting).

Can you provide any concrete examples of that actually being an issue?

Reason for this GR is concrete examples (thankfully believed solved by 
now) of it actually being an issue regarding init systems.


> And yet we don't stop applications from declaring "Architecture: 
> linux-any".  And the world has not ended.  People who maintain 
> non-Linux kernels have a substantial amount of work to do, and I find 
> it very impressive how much they've gotten working.  Yet nobody has 
> proposed a GR forcing support for kFreeBSD or the Hurd; the people 
> working on them have simply *done the work*, and in some cases 
> successfully convinced others to do the same.

We do strongly discourage that, as codified in Debian Policy §5.6.8:

> Specifying a list of architectures or architecture wildcards other 
> than `any' is for the minority of cases where a program is not 
> portable or is not useful on some architectures.  Where possible, the 
> program should be made portable instead.

Notice the "should" near the end of above.

Do you consider init 1 more similar to kernel or more similar to PHP?


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private


signature.asc
Description: signature

Re: Tentative summary of the amendments

[Aigars Mahinovs]

First of all, Josh, thank you for the long and reasoned replies. I do
hope this back-and-forth is useful for others as well in the context
of this decision, that is why I am still keeping the debian-vote list
in the CC.

On 24 October 2014 19:18, Josh Triplett  wrote:
> Aigars Mahinovs wrote:
>> Forget about init scripts. Imagine booting up a system with
>> "init=/bin/sh" - it should be possible to run a command to start your
>> service from there (without any init system at all). If you depend on
>> other services, then those should be startable with simple commands
>> too. If that is possible, then all is fine.
>
> More seriously, no, your expectations are no longer realistic or
> reasonable.  It is already not possible *today* to run "simple commands"
> and end up with a working system; many services depend on other running
> services, and the thing gluing them together is an init system.

I am assuming that the person running the commands know about the
dependencies in the services and starts them up manually and in the
right order. Init system does *not* glue services together it only
starts them in right order with right options - after that init system
does not participate in the inter-process communication.

> It's perfectly reasonable, for instance, for a daemon to expect to be
> run as a non-root user, and be handed a low-numbered socket that it
> could not itself open.  It's not reasonable to require every daemon to
> reimplement that code itself, with all associated security requirements.

That is what tools like start-stop-daemon or daemontools are for.
There is no need to reinvent things for every daemon and there is no
need to hardlock them into the init system too.

>> If systemd adds socket activation and you daemon uses it it is fine
>> for the start up of that daemon to use socket activation.  If a user
>> is running another init system it is fine for socket activation not to
>> work, but a problem would be for your daemon to crash or hang on
>> startup because of this.
>
> Expect an increasing number of new upstream daemons to lack any code to
> daemonize themselves, or to start as root and drop privileges, when a
> perfectly reasonable and better-audited implementation already exists to
> launch the daemon as non-root with no forking.  And that's two of
> several hundred features.  You cannot expect all upstreams to
> *duplicate* functionality that already exists, nor to maintain such
> duplication indefinitely.

I can see how it is beneficial to use something like that by default,
but if you remove, for example, the command line options for
specifying port to bind to, then you loose all kinds of non-default
functionality, like the ability to run the same or a different version
of a service as a one-shot on high port by a regular user, to start up
a debug version locally,  Sure it is easier to write a daemon that
can only be started as a systemd service, but along with loosing
support for all other init systems you also loose a lot of
flexibility.

>> You may use the advanced features, if they are available, but can't
>> just assume that they will be. On the other hand it is fine to not
>> provide some functionality if the advanced init system features are
>> not available.
>
> Consider how ludicrous this would sound about any other software:
>
> "You may use the Linux kernel, if it's available, but you can't just
> assume that it will be.  On the other hand, it is fine to not provide
> some functionality if Linux is not available."
[snip]
> Now, as a wishlist bug, sure, you could request fallbacks; some software
> may implement them.  Currently, some software in Debian has done so for
> various dependencies.  Huge parts of Debian, however, have hard
> dependencies on Linux, glibc, X, and GCC, and those dependencies are not
> in any way unreasonable.

Actually, we kind of do that - such things are detected by configure
scripts, for example. But all your examples (except GCC) are systems
that applications have always been calling. Applications have never
been calling init system before. Try the same assumption with: bash,
Metacity, gnome-shell. "When you application is started, it might be
started by gnome-shell, in that case you may give gnome-shell an
indication about your startup animation, but you may be started by
something else, in that case you should still start, but it is fine
not to provide the correct startup animation."

I do like the kernel and architectures analogies. We don't have a
policy requiring software to work on all kernels/architectures. I
believe that this situation is different because of the difference in
starting conditions - imagine if in previous Debian release *all*
software worked on all architectures, including kFreeBSD and Hurd and
then TC declared that Linux/amd64 is the new default architecture
(like what architecture install image shows up on the homepage) which
is quickly followed by people introducing new versions of important
software that is "

Re: Tentative summary of the amendments

[Josh Triplett]

Aigars Mahinovs wrote:
> On 24 October 2014 17:14, Josh Triplett  wrote:
> >> The key difference is that until this year all packages worked on all
> >> init systems (as in you could start any service or application with
> >> any init system as PID 1, even with "init=/bin/sh").
> >
> > Until recently, it was a painful endeavor to be the upstream of a daemon
> > package, because init scripts were not portable between Linux
> > distributions; each distribution tended to have to write their own.
> > systemd actually viewed that as a *problem*, and *fixed* it; it *is*
> > fairly reasonable now to ship a .service or .socket or other unit file
> > upstream and expect distributions to not need to change it.
> 
> That is *not* what the discussion is about. It is *not* about init
> scripts. Forget about init scripts. Imagine booting up a system with
> "init=/bin/sh" - it should be possible to run a command to start your
> service from there (without any init system at all). If you depend on
> other services, then those should be startable with simple commands
> too. If that is possible, then all is fine.

"exec /lib/systemd/systemd". ;)

More seriously, no, your expectations are no longer realistic or
reasonable.  It is already not possible *today* to run "simple commands"
and end up with a working system; many services depend on other running
services, and the thing gluing them together is an init system.  You
cannot, for instance, just run "foo-daemon" or even
"/etc/init.d/foo-daemon start" for an arbitrary foo, not least of which
because that won't enforce the starting of things foo depends on.  In
turn, those dependencies may include DBus services, or udev-managed
devices and device events.  You can't run DBus services without DBus
(though systemd is actually working to fix that), and you can't generate
udev events without udev.  Without such mechanisms, software may well
fail to launch or operate correctly.  The world is more complex than
your model, and has been for far longer than systemd has existed.

Your init=/bin/sh system may well depend on an initramfs to successfully
boot.  You may not be able to type on your keyboard without running a
daemon (e.g. for a Bluetooth keyboard).  You might not even have a text
console without running a daemon.  Those daemons themselves may depend
on other services.

It's perfectly reasonable, for instance, for a daemon to expect to be
run as a non-root user, and be handed a low-numbered socket that it
could not itself open.  It's not reasonable to require every daemon to
reimplement that code itself, with all associated security requirements.

It's also reasonable for you to reimplement that functionality in some
other system, and convince upstreams to use your version instead.  For
instance, you might adapt a piece of software to work with inetd rather
than a .socket file.

> If systemd adds socket activation and you daemon uses it it is fine
> for the start up of that daemon to use socket activation.  If a user
> is running another init system it is fine for socket activation not to
> work, but a problem would be for your daemon to crash or hang on
> startup because of this.

Expect an increasing number of new upstream daemons to lack any code to
daemonize themselves, or to start as root and drop privileges, when a
perfectly reasonable and better-audited implementation already exists to
launch the daemon as non-root with no forking.  And that's two of
several hundred features.  You cannot expect all upstreams to
*duplicate* functionality that already exists, nor to maintain such
duplication indefinitely.

> > In practice, demanding that packages work with all init systems, or even
> > with *two* init systems, demands that they support the
> > least-common-denominator of functionality provided by those init
> > systems.  That effectively makes any new feature added to an init system
> > useless until duplicated.
> 
> Yes - the demand is to make sure that the least-common-denominator
> does actually minimally work.

I appreciate that you actually acknowledge this rather than avoiding it,
but nonetheless, no, arrogant demand refused; systemd, like the Linux
kernel and many other pieces of software, provides useful functionality
that other implementations do not have.  Ask others nicely with
convincing arguments and see if they'll do the work for you (many seem
willing to), or do it yourself, or create other upstream software with
different requirements that does not need systemd and package that
software.

> You may use the advanced features, if they are available, but can't
> just assume that they will be. On the other hand it is fine to not
> provide some functionality if the advanced init system features are
> not available.

Consider how ludicrous this would sound about any other software:

"You may use the Linux kernel, if it's available, but you can't just
assume that it will be.  On the other hand, it is fine to not provide
some functionality if Linux is not availab

Re: Tentative summary of the amendments

[Aigars Mahinovs]

On 24 October 2014 17:27, Josh Triplett  wrote:
>> In any case, this is uncharted territory, because (to my knowledge)
>> until systemd started integrating system level services into init
>> system itself, applications never depended on particular APIs of init
>> systems.
>
> Sure they did.  Applications depended on daemons which depended
> specifically on sysvinit functionality: /etc/init.d, /etc/rc?.d, LSB
> init script metadata, dependencies on specific scripts and their
> functionality.  It wasn't much, but it was something.

Did a deamon parse /etc/init.d/... files on startup to figure
something out? I don't think so. Those files in /etc are configuration
for sysvinit and not an API.

Sysvinit calls services, services do *not* call sysvinit. The
communication is only one way.

AFAIK the only API that sysvinit actually has is tellinit. And even
that is kind of optional. That makes it very easy to implement new
init systems. Even in-house custom init systems for specific reasons.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDUToARDfuuPVwwsWXiGdPwpQ_t9=18srw6hm5scirm...@mail.gmail.com

Re: Tentative summary of the amendments

[Aigars Mahinovs]

On 24 October 2014 17:14, Josh Triplett  wrote:
>> The key difference is that until this year all packages worked on all
>> init systems (as in you could start any service or application with
>> any init system as PID 1, even with "init=/bin/sh").
>
> Until recently, it was a painful endeavor to be the upstream of a daemon
> package, because init scripts were not portable between Linux
> distributions; each distribution tended to have to write their own.
> systemd actually viewed that as a *problem*, and *fixed* it; it *is*
> fairly reasonable now to ship a .service or .socket or other unit file
> upstream and expect distributions to not need to change it.

That is *not* what the discussion is about. It is *not* about init
scripts. Forget about init scripts. Imagine booting up a system with
"init=/bin/sh" - it should be possible to run a command to start your
service from there (without any init system at all). If you depend on
other services, then those should be startable with simple commands
too. If that is possible, then all is fine.

If systemd adds socket activation and you daemon uses it it is fine
for the start up of that daemon to use socket activation. If a user is
running another init system it is fine for socket activation not to
work, but a problem would be for your daemon to crash or hang on
startup because of this.

> In practice, demanding that packages work with all init systems, or even
> with *two* init systems, demands that they support the
> least-common-denominator of functionality provided by those init
> systems.  That effectively makes any new feature added to an init system
> useless until duplicated.

Yes - the demand is to make sure that the least-common-denominator
does actually minimally work. You may use the advanced features, if
they are available, but can't just assume that they will be. On the
other hand it is fine to not provide some functionality if the
advanced init system features are not available.

> And in many cases, the systemd-invented services and features fill a gap
> for which no previously implementation existed, so "used to work before"
> is quite inaccurate.  Not all features are optional; not every feature
> needs fallback code to cope with its lack.  Doubly so if such fallback
> code does not already exist.

If some software used to work before systemd there is no technical
excuse for it not working with other init systems after systemd
integration. If there was no socket activation before, it can not be
such an essential feature that you simply can not function without it.

-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/cabpywdx5+-wupusr3-jux9fjpgiyztg8yhpweeh8wjyqc99...@mail.gmail.com

Re: Tentative summary of the amendments

[Josh Triplett]

Aigars Mahinovs wrote:
> On 24 October 2014 13:33, Ansgar Burchardt  wrote:
> > So, if P has a hard dependency on systemd-as-pid1, why do you want to
> > take P away from me? Because people not liking systemd are more
> > important than people not caring about it or even being okay with it?
> 
> It is not about "people not liking systemd". It is about people using
> other init systems. The question is about how strongly do we feel
> about supporting this group of users.

"we" don't consistently feel any way in particular about supporting this
group of users.  People who care can do the work, as always.

> > I don't like some software too, but am sometimes required to use it
> > without an alternative. Can I demand that I can use packages without
> > said software? Like demanding libraries having to provide language
> > bindings for at least two languages so I don't have to use PHP[1]? :)
>
> Init system is special because there can be only one active in the
> system. If app1 depends on systemd (as PID 1) and app2 depends on
> runit (as PID 1) then it becomes impossible to use both apps (without
> changing init system and rebooting). Also IMHO init system should be a
> user choice and not dictated by other, unrelated, software.

Kernels are special because there can be only one active in the system.
If app1 depends on Linux and app2 depends on FreeBSD, then it becomes
impossible to use both apps (without changing kernels and rebooting).

And yet we don't stop applications from declaring "Architecture:
linux-any".  And the world has not ended.  People who maintain non-Linux
kernels have a substantial amount of work to do, and I find it very
impressive how much they've gotten working.  Yet nobody has proposed a
GR forcing support for kFreeBSD or the Hurd; the people working on them
have simply *done the work*, and in some cases successfully convinced
others to do the same.

(And analogously, non-Linux kernels such as FreeBSD often have
substantial shim layers providing Linux APIs for the purposes of porting
software.)

> In any case, this is uncharted territory, because (to my knowledge)
> until systemd started integrating system level services into init
> system itself, applications never depended on particular APIs of init
> systems.

Sure they did.  Applications depended on daemons which depended
specifically on sysvinit functionality: /etc/init.d, /etc/rc?.d, LSB
init script metadata, dependencies on specific scripts and their
functionality.  It wasn't much, but it was something.  Consider the
burden that placed on other init systems.  Consider what would happen if
a new init system came along, which did *not* implement the sysvinit
interfaces; would we suddenly force applications to stop depending on
sysvinit features?  Or would we simply say "patches welcome"?

In any case, even if this problem were new to init systems, it's not new
to many other things: kernels, C libraries, compilers, and many other
things.

> We need to make a conscious decision on how to handle that. If we
> don't then it is likely that the process will go on as before:
> * systemd introduces a great new system level service,

How dare they build software people want?

> * key apps depend on that service to do great things (and stop working
> on all other init systems),

How dare they take advantage of time-saving common code, or introduce
new functionality for which no support previously existed?

> * people using other init systems are sad,

"How dare other people do work on init systems other than ours?"

> * after a lot of hard work a new ugly hack shows up to patch out or
> fake out the new service (making apps kind of work again, but not as
> good as before),
> * another flamewar/GR is started to stop systemd dependencies breaking
> software for other people

Yeah, sadly, I don't expect this to be the last flamewar on the topic,
even after it gets voted down.

> * (repeat)

Modulo the flamewar/GR, that's the normal, expected, and desirable
process.  It also has the critically important property of only
continuing as long as enough people actually want to do the work, rather
than becoming self-perpetuating as a GR-enforced requirement would.

> I am sure that there will be several more rounds of these because
> systemd has a *lot* of very interesting and useful services coming up
> in their plans.

I already expect to see several more rounds over *existing* services
that the systemd package hasn't yet enabled.  For instance, timesyncd,
networkd, systemd-nspawn, etc.  I anticipate a painfully long delay
before I can actually count on those.

> I can't wait to use most of them, but at the same time
> it sound like they are developed in a tight coupling with systemd
> itself thus making all those very useful features unavailable to users
> of all other init systems. Like the upcoming wifi management changes -
> those sound great, but there doesn't seem to be a reason why it
> couldn't have been designed in such way that users of o

Re: Tentative summary of the amendments

[Josh Triplett]

On Fri, Oct 24, 2014 at 03:50:48PM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 15:40, Josh Triplett  wrote:
> > What makes the systemd case so drastically different that those who care
> > about alternative init systems cannot follow the same procedure?
> 
> The key difference is that until this year all packages worked on all
> init systems (as in you could start any service or application with
> any init system as PID 1, even with "init=/bin/sh").

Until recently, it was a painful endeavor to be the upstream of a daemon
package, because init scripts were not portable between Linux
distributions; each distribution tended to have to write their own.
systemd actually viewed that as a *problem*, and *fixed* it; it *is*
fairly reasonable now to ship a .service or .socket or other unit file
upstream and expect distributions to not need to change it.

And when functionality is missing, it's possible to get that
functionality added; how long has it been since sysvinit added a new
useful feature that daemons could use?

Until recently, if you wanted your service to be restarted if it
crashed, you had to use one of various separate packages to do so;
sysvinit simply didn't *do* that.  It *could* have; I'd love to know
where we'd be a decade ago if sysvinit had had an /etc/inittab.d.  A
quick search turns up people asking for that in *1999*.

There's a reason that systemd has had a meteoric adoption rate: it
provides a huge number of features people not only want, but have wanted
for years.

In practice, demanding that packages work with all init systems, or even
with *two* init systems, demands that they support the
least-common-denominator of functionality provided by those init
systems.  That effectively makes any new feature added to an init system
useless until duplicated.

> The fact that the regression is introduced by an architectural
> decision of systemd developers to tightly integrate system level
> services into the init system (and not by a decision in Debian) causes
> the feeling of loss of control.

That's a very legitimate and accurate feeling.  The people not doing the
work don't have control.  The people who are doing work on alternative
implementations do have control of those implementations, and can make
them as loosely coupled as they like.

> Then asking others to implement
> init-system-neutral versions of systemd-invented services just to keep
> using software that used to work before is ... raising some hackles.

"asking" for such alternative implementations isn't raising hackles;
*demanding* is raising hackles.  Even worse yet are the folks instead
demanding that upstreams simply not use such services, or who insist
that no possible use exists for such services.

And in many cases, the systemd-invented services and features fill a gap
for which no previously implementation existed, so "used to work before"
is quite inaccurate.  Not all features are optional; not every feature
needs fallback code to cope with its lack.  Doubly so if such fallback
code does not already exist.

- Josh Triplett


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024141435.GA16989@thin

Re: Tentative summary of the amendments

[Miles Fidelman]

Aigars Mahinovs wrote:

On 24 October 2014 12:35, Ansgar Burchardt  wrote:

In fact, they want to require that if P supports only A (and not A|B)
that the maintainers of P have to patch P to make it support B. In the
good old days[tm] it would be the responsibility of the people wanting
to use B to submit patches to make P work with B (but here I suspect
many people demanding support for B do not even use P[1]...).

   [1] In particular I heard somebody asked if anybody wanted to help
   with this work and from my understanding the response was not
   very enthusiastic... Why patch something you don't use after all?

The root of the problem is coming from upstream not caring about
alternative init systems. To take the logind case as an example - each
of the dependencies from GDM to systemd make perfect sense in
isolation. However, the end result (was) that GDM only worked with
systemd almost by accident. No developer in that chain was compelled
to run this under other init systems.




All this talk about what upstream developers will and won't do. Seems to 
me that they've been writing sysvinit scripts for years; systemd support 
ADDS work.  It's only the GNOME developers who are being rather vocal 
about not supporting sysvinit, to the extent of IMHO blackmail.


Miles Fidelman

--
In theory, there is no difference between theory and practice.
In practice, there is.    Yogi Berra


--
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/544a5a91.8040...@meetinghouse.net

Re: Tentative summary of the amendments

[Hubert Chathi]

On Fri, 24 Oct 2014 10:21:01 +0200, Holger Levsen  said:

> Hi Uoti, thanks for your summmary of the situation.

> On Donnerstag, 23. Oktober 2014, Uoti Urpala wrote:
>> In another mail, Ian said that his interpretation is that the init
>> system would not only have to be packaged in Debian, but in testing
>> and not RC buggy.

> yeah, I found this interpration also "interesting"... (eg. that there
> is room for interpretaion... I thought "in Debian" ment sid and could
> be buggy. Now I learn that buggy packages in sid seem to not always be
> part of Debian... at least not in the context of this amendment.) -
> interesting and a bit scary.

Apologies to Ian for opening yet another can of worms.  I thought that
my request for clarification was for a fairly straightforward issue...

Without wanting to put any words into Ian's mouth, I believe the intent
is that any package can be installed with at least two init systems that
are supported by Debian.  In particular, a user should not have to go
outside of the repository that they installed the package from.  So if a
package foo in stable depends on init1 | init2 | ..., then at least two
of init1, init2, ... should be in stable.

How do packages get in stable?  They must be in testing first, so Ian
saying that the alternative init system must be in testing seems
reasonable from the viewpoint of releasing stable.  And if the init
system has an rc bug (that is not labelled *-ignore), then it won't make
it into stable either.  So if an init system fails the conditions that
Ian gave, then it will not be in the next stable release.

I believe that what Ian is trying to avoid is the situation where
package foo depends on init1 | init2 | ... but only init1 is in testing,
and init2, ... are all in unstable and in no condition to be part of the
next release, and then we eventually release stable with only foo and
init1, but not init2 | ...  Basically, you shouldn't be allowed to get
around the requirements of Ian's proposal by using some broken,
non-release-quality init system as your alternative; the alternative
init system must be something that users can actually use.

The wording that Ian used isn't what I would have used -- I would have
said that the alternative init system must be available from the same
(repository|distribution|Debian version) as the package the user wants
to install -- but I think the intent and the effect is pretty much the
same as what Ian said, especially when seen from the point of view of
stable.

-- 
Hubert Chathi  -- Jabber: hub...@uhoreg.ca
PGP/GnuPG key: 1024D/124B61FA http://www.uhoreg.ca/
Fingerprint: 96C5 012F 5F74 A5F7 1FF7  5291 AF29 C719 124B 61FA


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87wq7pbmfu@desiato.home.uhoreg.ca

Re: Tentative summary of the amendments

[Olav Vitters]

On Fri, Oct 24, 2014 at 04:02:24PM +0300, Aigars Mahinovs wrote:
> That is not what is actually required. It is sufficient to handle the
> situation when such functionality is not available. That is inside the

So in case functionality is not available in more than one init system,
upstream cannot rely on that functionality. You're directing how the
package should be developed, while not being part of the developers.
Obviously you can have various requirements, but it has to make a bit of
sense. Here, it's demanding something from the wrong group. As mentioned
a few times before: open for discussion, demands like this are going to
be ignored. If you'd read up, you'll notice that upstream does care and
has done loads of work.

I'd still summarize your rephrase as the same thing: realistically
you're demanding the extra functionality to be done by upstream.

You really get better results with assuming that as an upstream we do
care instead of assuming the worst and being demanding.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024133209.gd32...@bkor.dhs.org

Re: Tentative summary of the amendments

[Anthony Towns]

On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> On 24 October 2014 13:15, Anthony Towns  wrote:
> > On Fri, Oct 24, 2014 at 12:57:49PM +0300, Aigars Mahinovs wrote:
> >> No developer in that chain was compelled
> >> to run this under other init systems.
> > Well, yeah:
> > "1. Nothing in this constitution imposes an obligation on anyone to do
> > work for the Project."
> > Compelling developers isn't something that can be done in Debian.
> No, but we set up requirements that their work must meet before it can
> enter archive or may end up in a release. 

Sure, but isn't that just /how/ you compel them? 

If you were literally beating people with a stick for not testing their
packages with other init systems, that would certainly be compulsion, no?
Using policy and RC bugs as a metaphorical stick to beat people with
would similarly be compulsion, in my view.

Looking at it from a game theory approach, assume you've got two groups of
people -- those who use systemd (S), and those who don't (U); and two actions
those groups can take -- work on support for non-systemd init systems (W) or
leave it to someone else (L).

Assume the cost of doing the systemd suport is "-2", the cost of doing
the SysV support is also "-2", and the cost of having the software not
available for you is "-5".

Without any compulsion for systemd folks to work on non-systemd support
the cost grid for a daemon maintained by systemd users who've written
a .service file:

SL   SW
UL U=-5 U=0
   S=-2 S=-4
UW U=-2 U=-1
   S=-2 S=-3

In that case, there is no incentive for systemd folks to do the actual
work for non-systemd stuff -- it's just work for them and no benefit. For
non-systemd folks, there's a benefit to doing the work if systemd folks
don't, and a cost to doing it if systemd folks are doing it anyway. So
the stable solution is for the non-systemd users to do the work of
maintaining the non-systemd support.

If systemd folks are "compelled" (encouraged, whatever) to do the work
to maintain non-systemd support because software won't be included in
Debian if it's systemd only, that matrix changes to:

SL   SW
UL U=-5 U=0
   S=-7 S=-4
UW U=-2 U=-1
   S=-2 S=-3

Here, things change -- it's worst for everyone if nobody does the work,
but if someone else is doing the work, it's better for you to let them
do it. That's the opposite of the prisoner's dilemma, in that both
non-systemd and systemd users are better off if they "cooperate" by
working on non-systemd support (as opposed to "defecting" by not working
on it), but that's only true given there's compulsion in the first place.

If you compare with and without the compulsion, the only circumstance
that's different is that S is worse off if S and U both choose L, ie
not-working on systemd support.

I'm not sure that the GR proposals actually setup that sort of payoff
matrix, though that's the impression that I get. If it is, I think
"compelled" is a fair description of what's being attempted.

(You could take the above argument to an extreme and say that policy
should never matter, and everything should end up in the release,
no matter what "bug" it might have. For me, the question is whether
including a package in the distro makes the distro as a whole worse than
not having it. Packages with security holes and data loss bugs match that
criteria for me, while packages that only work with systemd (or upstrart)
don't. If you could imagine including the package in a "kubuntu"-esque
variant of Debian which took the opposite policy and being useful to
users, then I suspect its bugs probably shouldn't be considered RC)

Cheers,
aj


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024133236.ga32...@master.debian.org

Re: Tentative summary of the amendments

[Ritesh Raj Sarraf]

In the entire systemd conversation, there's hardly been any discussion
about non-desktop stuff. Or has there ? I may have missed. I've mentioned
this previously in some of the bug reports, maybe do here too.

How are other packagers taking care of it ? There are a lot of server
daemons that need some sort of housekeeping. What I can recall immediate
are: mysql, open-iscsi, DM multipath etc.. Last feedback (IIRC _not_ from
the systemd maintainers) I had on it was to write a shell script, and call
it from the systemd unit.

I just checked my mysql server package, and it is not shipping any systemd
service file. Is it just a matter of time that they will start shipping ?

Are we reaching out to all affected parties ? An init system touches a lot
of other components in an OS, not just the desktop interface to
sleep/hibernate/reboot/shutdown.

On Fri, Oct 24, 2014 at 6:32 PM, Aigars Mahinovs  wrote:

> On 24 October 2014 15:33, Olav Vitters  wrote:
> > On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> >> No, but we set up requirements that their work must meet before it can
> >> enter archive or may end up in a release. That is what the whole of
> >> Debian Policy is about.
> >
> > That is things within the package itself. This is about doing extra
> > work. In case you rely on functionality which is only provided by one
> > init system, ensure the functionality is also available on other init
> > systems.
>
> That is not what is actually required. It is sufficient to handle the
> situation when such functionality is not available. That is inside the
> package and it has many different uses (different init, no init,
> restricted chroot, system in some weird state, API changed, ...). You
> can even hide that code behind a command-line option or a
> wrapper-script (so you don't have to detect availability of feature
> and instead rely on being called with a special option or name when
> extra functionality does not exist). No one is forcing you to
> implement features into another init system, so that is a strawman.
> --
> Best regards,
> Aigars Mahinovsmailto:aigar...@debian.org
>   #--#
>  | .''`.Debian GNU/Linux (http://www.debian.org)|
>  | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
>  | `. `'Linux Administration and Free Software Consulting   |
>  |   `- (http://www.aiteki.com) |
>  #--#
>
>
> --
> To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmas...@lists.debian.org
> Archive:
> https://lists.debian.org/CABpYwDWTeyfD2PixwTSOy5VW4sXhkq=36rmpfxhjaizd7mq...@mail.gmail.com
>
>


-- 
Ritesh Raj Sarraf
RESEARCHUT - http://www.researchut.com
"Necessity is the mother of invention."

Re: Tentative summary of the amendments

[Aigars Mahinovs]

On 24 October 2014 15:33, Olav Vitters  wrote:
> On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
>> No, but we set up requirements that their work must meet before it can
>> enter archive or may end up in a release. That is what the whole of
>> Debian Policy is about.
>
> That is things within the package itself. This is about doing extra
> work. In case you rely on functionality which is only provided by one
> init system, ensure the functionality is also available on other init
> systems.

That is not what is actually required. It is sufficient to handle the
situation when such functionality is not available. That is inside the
package and it has many different uses (different init, no init,
restricted chroot, system in some weird state, API changed, ...). You
can even hide that code behind a command-line option or a
wrapper-script (so you don't have to detect availability of feature
and instead rely on being called with a special option or name when
extra functionality does not exist). No one is forcing you to
implement features into another init system, so that is a strawman.
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDWTeyfD2PixwTSOy5VW4sXhkq=36rmpfxhjaizd7mq...@mail.gmail.com

Re: Tentative summary of the amendments

[Olav Vitters]

On Fri, Oct 24, 2014 at 01:48:33PM +0300, Aigars Mahinovs wrote:
> No, but we set up requirements that their work must meet before it can
> enter archive or may end up in a release. That is what the whole of
> Debian Policy is about.

That is things within the package itself. This is about doing extra
work. In case you rely on functionality which is only provided by one
init system, ensure the functionality is also available on other init
systems. This is not within the scope of a tarball/package. It's
demanding to write e.g. "systemd-shim" else package won't be kept in
Debian.

-- 
Regards,
Olav


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141024123346.gb32...@bkor.dhs.org

Re: Tentative summary of the amendments

[Aigars Mahinovs]

On 24 October 2014 15:40, Josh Triplett  wrote:
> What makes the systemd case so drastically different that those who care
> about alternative init systems cannot follow the same procedure?

The key difference is that until this year all packages worked on all
init systems (as in you could start any service or application with
any init system as PID 1, even with "init=/bin/sh").

The fact that the regression is introduced by an architectural
decision of systemd developers to tightly integrate system level
services into the init system (and not by a decision in Debian) causes
the feeling of loss of control. Then asking others to implement
init-system-neutral versions of systemd-invented services just to keep
using software that used to work before is ... raising some hackles.
-- 
Best regards,
Aigars Mahinovsmailto:aigar...@debian.org
  #--#
 | .''`.Debian GNU/Linux (http://www.debian.org)|
 | : :' :   Latvian Open Source Assoc. (http://www.laka.lv) |
 | `. `'Linux Administration and Free Software Consulting   |
 |   `- (http://www.aiteki.com) |
 #--#


-- 
To UNSUBSCRIBE, email to debian-vote-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: 
https://lists.debian.org/CABpYwDUhEAAeTYQXbBeMKuiFi8qzbp766=xw6wycajs7ptf...@mail.gmail.com