Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Russ Allbery]

I'm going to make a similar point to Sam's but in a slightly different
way that hopefully will help.  (Also, I apologize for sounding rather too
absolute in my initial response to your proposal.  There were better ways
of phrasing my concerns.)

Guillem Jover  writes:

> I'm actually not sure how the other options can be seen as resolving the
> root issue at hand. I see what they are trying to do, but I don't think
> they are framing it correctly. They are all approaching the problem from
> the symptoms, by either trying to go into details on how to integrate
> specific stuff, or on how to behave. This all feels like they assume
> that people would not respect the spirit of a decision, and to combat
> bad faith they need to be very specific on details? But if we'd assume
> people are going to be acting in bad faith, then no amount of details
> and specifics would fix this, and IMO it can make it worse, as it gives
> a list of things to be looking loop holes into and questioning
> legalities all over. I think this is a recipe for disaster, and I also
> find that type of framing a bit depressing.

This isn't how I think about the options.  I don't think people are going
to behave in bad faith.  Rather, I think the problem is what Sam alluded
to: General statements of principle are more open to interpretation than
their authors think that they are.

With full respect and credit to those who have different goals for this
GR, I personally am largely uninterested in the project making a general
statement of principles about integrating technology.  To be frank, I'm
dubious of such statements.  I don't think they're always helpful.  I also
think the principles of Debian developers are highly diverse (which is
great), and perhaps our goal should not be to try to get everyone in
Debian to align on the same principles, but instead to make practical
decisions that can be supported from a variety of principles.

The problem I want to solve is that we need to make three work-blocking
decisions:

1. Is every package that wants to start a service always, sometimes, or
   never required to include an init script?  If they are, at what bug
   severity and with what consequences if this is not done?

2. Are package maintainers allowed to use systemd-exclusive facilities
   that would improve system integration for systemd users or improve
   other goals (such as security) at the cost of compatibility with other
   init systems?  If so, what process should we use for adopting those
   facilities?

3. How much effort is the project committing to undertaking to incorporate
   alternatives to major systemd ecosystem components (such as elogind)
   that are not drop-in replacements, either due to their own
   implementation limitations or because our dependency system or other
   tools makes drop-in replacement difficult?

As one of the Policy editors, I am primarily concerned with 1 and 2.  I'm
only an interested bystander for 3 (ideally Policy should have something
to say here, but we haven't gotten there).

I see huge value in the project making those decisions without regard to
whether the project can agree on principles underlying those decisions.  I
don't want to argue about interpretation of some general, non-specific
statement.  I want the project to make some decisions.

I believe that we have already exhausted or ruled out other project
mechanisms to make these three critical technical decisions (Policy
process, debian-devel discussion, and the Technical Committee).  I think
delegatd teams and the Technical Committee are (correctly!) unwilling to
speak for the project on these closely-divided and highly divisive issues.

Debian is constituted as a democracy of developers.  The project makes
technical decisions of last resort via vote.

We've put off this decision as long as we reasonably can, we've tried for
five years to let the discussion calm down and to find some alternative
method of reaching consensus, we've waited to see if some
nonconfrontational approach will evolve, and people are still sniping at
each other.  Meanwhile, work that people want to do in Debian, whether
that be better support for non-systemd systems or taking advantage of
valuable systemd features such as ProtectSystem or DynamicUser, is often
blocked on these decisions with no clear prospect for resolution or
unblocking.

You may have noticed in these discussions that I'm not talking about my
own opinion about what the decision could be.  I have an opinion, but I've
spent enough energy attempting to convince other people of my opinions on
init systems for one lifetime.  On this vote, I'm on team "make a decision
already, whatever that decision is," and the position I'm advocating here
is please do not kick the can even farther down the road.


Towards that end, here are the specific implications of the various
options that I anticipate for Policy.  Please note that this is just my
personal opinion as one of the Policy editors.  Sean doubtless 

Re: My analysis of the proposals

[Sam Hartman]

> "Uoti" == Uoti Urpala  writes:
Uoti> I still don't really see why you disagree with my view (not
Uoti> exactly a "proposal").

Uoti> Which of these do you disagree with?

As someone charged with facilitating discussions within Debian, I'm
asking you to stop this thread now.
It's obvious there is some lingering misunderstanding, but I do not
believe this discussion on -vote will be served by exploring it further.

It seems clear that:

* There are people here who value being able to use sysvinit.

* There are people here who would value Debian deciding not to support
  sysvinit.

* We respect both these views, and deciding among them is one potential
  outcome of the current GR process.

I don't think it was your intention to escalate the situation, but that
seems to be happening, and I'd ask you to step back rather than
continuing.

Sam Hartman
Debian Project Leader.


signature.asc
Description: PGP signature

Re: My analysis of the proposals

[Paul Tagliamonte]

On Tue, Dec 03, 2019 at 01:31:53AM +0200, Uoti Urpala wrote:
> The relevant question now is not "should Debian support anything that
> is not systemd", but "should Debian support sysvinit". In case any
> promising systems appear in the future, decisions about them are best
> left for when it's not arguing about hypotheticals.

I know I'm going to regret wading in here -- but maybe I can help?

Uoti -- Remember when reading this rest of this message that from what I
can understand from what you've written, we will likely vote nearly the
same way on this GR. I've not hid the fact that I vastly prefer systemd
to sysvinit, and don't really care about sysv anymore (sorry not sorry?).

However:

This is not the right place to have this discussion. I don't think
trying to hash this out here is productive, and largely isn't adding to
the substance here.

We need to have this GR **not** to rehash the last god knows how many
years since "the bug" was filed, but to provide direction to the project
on what we should be doing (on a technical level) when it comes to
supporting multiple init systems.

The options provided are to show us a way out of this mess. I don't
think trying to comapre and contrast is helpful or even relevant to this
vote at all. The technical merits are largely not in play and shouldn't
factor in to the vote too much.

Please can we stop this discussion and getting baited into talking about
the technical merits of pid 1?

   paultag

-- 
 .''`.  Paul Tagliamonte 
: :'  : Proud Debian Developer
`. `'`  4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
 `- http://people.debian.org/~paultag


signature.asc
Description: PGP signature

Re: My analysis of the proposals

[Russ Allbery]

Uoti Urpala  writes:

> I don't doubt that there exist people for whose needs an existing
> sysvinit system can be perfectly adequate. Just like there are people
> for whose needs an old 80286 computer is adequate. But I don't think
> that contradicts with "is obsolete" or "is a technological dead end".

I encourage you to take a step back and think through what you're trying
to accomplish by using phrases like that.  Do you expect someone who wants
to continue to run sysvinit for the time being to see a statement from you
that sysvinit is obsolete or a technological dead end and think "oh, I
never considered that, I guess I should stop using it"?

In other words, I don't think it matters whether or not those statements
are correct because, regardless of whether they are correct, they are not
persuasive.

Saying that something is obsolete in the free software world is
essentially a forecast.  Because free software can always form the basis
for additional development, it's making a *prediction* that no one is
going to use that specific piece of software as a basis for future
development or keep it working for new use cases.  It's difficult to make
predictions, especially about the future [1].

Making non-persuasive statements of position like this doesn't come across
as participating in a discussion or attempting to find common ground or
shared goals.  Instead, it provides tribal signaling: you are aligned with
the "stop supporting sysvinit" camp and you want everyone else to know
that.

My position is that those statements are not useful, and indeed are
actively harmful, for the following reasons:

1. We're about to hold a vote, which is the formal way in which Debian
   developers can decide what position they want to take.  While
   persuasive arguments may be useful before a vote, declarations of
   voting intention are less useful (unless they are an argument for
   making a change to a proposal).  There's no point in voting before we
   vote.  (I don't remember if you are a Debian developer; if not, perhaps
   your goal is to persuade other people who can vote.  However, as
   mentioned, these sorts of statements are not persuasive to people who
   disagree with you.)

2. Voting via mailing list post just encourages other people to also vote
   via mailing list post because they're worried that silence seems like
   disagreement, and then the thread degrades into a bunch of people
   stating their (unsurprising and already known) positions, which is both
   noisy and demoralizing.

3. It's extremely hard to make statements like this without having them
   come across as implicit, or even explicit, attacks on people who
   disagree with you.  (And you're not currently succeeding at that, IMO.)

In my opinion, it is very, very unlikely that anyone is going to come up
with a new, insightful, and perceptive argument about init systems that is
going to change a bunch of people's minds in the course of a debian-vote
thread, given the past six (!!) years of project discussions.  We've
already heard all the arguments.  Many times.  This is why the discussion
has focused on process and on ensuring the voting options reflect the
possible ways forward, rather than on the merits of the positions.

[1] https://quoteinvestigator.com/2013/10/20/no-predict/

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

Re: My analysis of the proposals

[Uoti Urpala]

On Mon, 2019-12-02 at 21:37 +0200, Wouter Verhelst wrote:
> For those who think that sysvinit is good enough, and that the problems
> for which systemd provides a solution are not problems to begin with,
> there is nothing wrong with the premise of "try to keep sysvinit at 2014
> levels indefinitely", on the contrary. So, while it's a valid question

I don't doubt that there exist people for whose needs an existing
sysvinit system can be perfectly adequate. Just like there are people
for whose needs an old 80286 computer is adequate. But I don't think
that contradicts with "is obsolete" or "is a technological dead end".
There are reasons why support for some software should be low priority
even if it's not yet literally absolutely useless for everyone.


> As such, I don't think, and vehemently disagree with your stated
> proposal, that we should decide anything on sysvinit in particular,
> other than through the more general question of "should Debian support
> anything that is not systemd".

I still don't really see why you disagree with my view (not exactly a
"proposal").

Which of these do you disagree with?

fact: The conflicts that occur in practice are about sysvinit support.

fact: There is in practice no development of new alternative init
systems happening, and no clear reason to believe that if it
hypothetically did occur, there would be particular problems. Certainly
there are no concrete problems in need of resolution.

consequence: How clearly a decision resolves conflicts is determined by
how clearly it decides the question of sysvinit support.

consequence: Talking about "other init systems" in general is either
misleading, insofar as it's about policies that only have practical
effect through application to sysvinit, or about uncertain
hypotheticals that are in no particular need of resolving at this time.


The relevant question now is not "should Debian support anything that
is not systemd", but "should Debian support sysvinit". In case any
promising systems appear in the future, decisions about them are best
left for when it's not arguing about hypotheticals.

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Sam Hartman]

> "Guillem" == Guillem Jover  writes:

Guillem> The key here, I guess, is that each situation needs to be
Guillem> evaluated independently, and no magic decision tree will
Guillem> ever fix trying to work things out with other people, in
Guillem> good faith, and trying to find solutions or compromises
Guillem> that satisfy others and us too. But maybe this is asking
Guillem> too much, dunno. :/

Hi.

I strongly agree with the above--that things need to be evaluated on a
situation-by-situation basis.

I'm responding not in the hopes of convincing you or persuading you (or
really anyone else).
It's obvious that we see the world differently.

However, I feel that if I simply said nothing, I would not be respecting
the thought you've put into your proposal and to your position.

So, I'm responding to say that I've tried to listen and understand where
you're coming from, and to show where I think our differences are.
Thanks for the work that you put into this.  While I disagree, I value
what you've done here.

My experience in leading groups to consensus is that it is often much
easier to focus on specific details and specific situations than on
general principles.

It is very easy to get people to  appear to agree when you are talking
about generalities that can be widely interpreted.
However, in practice when you go try and apply those generalities to
specific cases, you find that the same divisions exist and that the
generalities don't help much.
There are exceptions: I think the Social Contract has done significant
good for the project.

In my experience those exceptions tend to be agreements to general
principles not born out of conflict, but rather out of a community's
desire to define itself.

In contrast, when there is conflict, I've found that you get better
results focused on specifics.

But Guillem is right that as we move forward we'll find things where the
specific details we focus on in this GR do not apply.  We'll also find
cases where circumstances have changed, we have new information, or new
ways of thinking about something emerge.

At that point, we can (and I think should) start to derive general
principles from the specifics we adopt in the GR.
I hope we take this GR as the feeling of the project at a single point
in time and accept that things will change.  I hope that we do not force
ourselves to have future GRs to revisit aspects of what we decide in the
coming weeks when we can come to agreement that things have changed.

I respect that this is an area where people can look at the world
differently.  Thanks for placing option G on the ballot: if the project
believes that focusing on principles is the right way forward here, we
now have a way to concretely express that.


signature.asc
Description: PGP signature

Re: Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Marco d'Itri]

guil...@debian.org wrote:

> * The traditional-only way camp: This group outright rejects things
>   like systemd, and other similar technologies. Some of this group was
>   part of Debian in the past, but found a new home in Devuan. People
I read all my emails with mutt (which I used to maintain) and the news
with tin (which I still maintain).
I send all my emails over UUCP.
My desktop is fvwm (with parts of GNOME!)
My terminals are 80x25.
I maintain Fidonet-related software.
My favourite programming language is Perl.
I use IRC all the time and I despise Slack.
I judge people who send HTML emails or top quote or have signatures
longer than 4 lines.

I am quite fond of my traditions but I still recognize the systemic
benefits provided by only supporting systemd: I do not accept for this
issue to be framed as "tradition vs. progress".

-- 
ciao,
Marco

Reframing (was Re: Proposal: Reaffirm our commitment to support portability and multiple implementations)

[Guillem Jover]

Hi!

[ I'm sorry this has gotten a bit long, but I assume I'm going to run out
  of time for any discussion, due to the imposed timeline, so I'm trying
  to put it all upfront. ]

On Sat, 2019-11-30 at 11:54:09 -0700, Bdale Garbee wrote:
> Guillem Jover  writes:
> > I think the current GR is incorrectly framing the problem at hand,
> > as if it was just an init system selection.
> 
> This resonates with me, but...
> 
> > I'm thus proposing the following:
> 
> I find this really appealing as a higher-level statement of values and
> intent, but unfortunately, I don't think the text does anything to help
> resolve the problems that Sam set out to try and tackle with this GR.
> 
> I therefore find myself unwilling to second it, even though on some
> level I would really like to.

I've to say, that while I think I understand where your and other similar
reactions to this proposal are coming from, I also found them a bit
perplexing. :)

Other options
-

I'm actually not sure how the other options can be seen as resolving
the root issue at hand. I see what they are trying to do, but I don't
think they are framing it correctly. They are all approaching the problem
from the symptoms, by either trying to go into details on how to integrate
specific stuff, or on how to behave. This all feels like they assume that
people would not respect the spirit of a decision, and to combat bad faith
they need to be very specific on details? But if we'd assume people are
going to be acting in bad faith, then no amount of details and specifics
would fix this, and IMO it can make it worse, as it gives a list of things
to be looking loop holes into and questioning legalities all over. I think
this is a recipe for disaster, and I also find that type of framing a bit
depressing.


The options that favor focusing on systemd still seem to leave the door
open in appearance to alternatives, but in some kind of false sense of
hope way, due to either the proposed vague hopes or all the conditionals
which depend on maintainer discretion to apply based on the (naturally
insufficient) details provided on those options. It seems like a death
by a thousand cuts, which sets the stage for more frustration and
conflict.

The options that favor init alternatives go into specific details (are
these truly exhaustive enough though?). But they still seem to not be
asking the right question.


Let's skim over the other options:

* Option F

  - The "cross-distro and standardization efforts" mention feels a bit
misleading to me, as this is really restricted to an ecosystem
based on Linux + glibc + systemd. (To clarify, I think this is
obviously a valid stance to take, I mostly take issue in the way
it is presented.)
  - Provides a false sense of hope (see above):
+ "patches _can_ be submitted".

How is this going to prevent the same situations that triggered this
GR?

* Option B

  - Provides a false sense of hope (see above):
+ _Should_ include unit and init scripts.
+ Developers and user _can_ explore and develop alternatives.
+ Developers need to provide the work, but that does not imply others
  will integrate it.
+ Reviewing and discussing patches but obviously not necessarily
  agreeing to them.

How are any of these going to prevent the same situations that triggered
this GR?

* Option A

  - Provides a false sense of hope (see above):
+ Focuses on sysvinit specifics like init script, but does not
  mention other potentially ancillary features upstream might use
  that are not core functionality to the project at hand.
+ The NMU reference looks like a distraction, as it does not fix any
  possible deadlock or blocking, as one can always reject an NMU, or
  revert it.
+ In Debian, policy (in most cases) follows practice, so whether policy
  accepts something does not say much about what maintainers will be
  accepting.

How are any of these going to prevent the same situations that triggered
this GR?

* Option D

  - Goes into much detail about possible conflicting scenarios, but does
it cover them all? This seems inherently non-exhaustive.
  - This encodes very concrete package names and implementation details,
which seem off for a GR.
+ What if the sysvinit maintainers and users agree they want to switch
  to something else on top of sysvinit that does not use traditional
  init scripts?
  - Isn't option D.7 potentially very counterproductive? Mixing regressions
in support with new support seems murky. Also what kind of patch are
we talking about? A 10 liner, or 1 MiB of delta which upstream is not
willing to take, so the burden falls on the Debian maintainers?

* Option E

  - What does the "MUST" and "work" in here really imply? Does this mean
every package must fully support natively all currently available init
systems in Debian (runit, s6, etc)? Or say, the day after this option
wins, 

Re: Question Under Proposal D: Compile Time Option

[Florian Weimer]

* Neil McGovern:

> On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote:
>> On 11/29/19 11:32 PM, Sam Hartman wrote:
>> > Imagine that we have a program that has compile time support for systemd
>> > and for other mechanisms.  It provides enhanced functionality when built
>> > against systemd, but when so built, it cannot run without systemd.
>> > 
>> Is this a real life case (if so, please name the package...), or just a
>> pure fictional one, just because you love debating?
>> 
>
> Or a hypothetical one, but one which could be fairly reasonable to
> expect. This GR seems to be trying to put in place a statement on what
> exactly we mean by support, and so considering things which may
> reasonably happen in the future is something that we should do.

It's certainly what we have seen with SELinux, where support causes
packages to grow additional library dependencies.  Even though
libselinux is overall quite benign (even Fedora and downstreams do not
*require* that the kernel activates SELinux), I'm sure it initially
caused problems for chroot setups.

If we're Going to Have Alternate Init Systems, we need to Understand Apt Dependencies

[Sam Hartman]

> "Ansgar" == Ansgar   writes:

Ansgar> Adam Borowski writes:
>> * dependencies on "systemd | other" rather than "other |
>> systemd"; this is a no-op on a systemd system (installed by
>> debootstrap before any non-base packages) but causes apt to force
>> an init+rc switch elsewhere

Ansgar> It's very likely not a no-op on systemd systems as
Ansgar> significantly more people somehow got systemd-shim installed
Ansgar> than had sysvinit-core, see for example [1] which shows that
Ansgar> somehow the "no-op" results in systemd-shim getting
Ansgar> installed (which caused problems in the past).

Ansgar> Just because you don't observe unwanted behavior happening
Ansgar> right now on your system doesn't imply it doesn't exist.
Ansgar> And the unwanted behavior that you say wouldn't happen (as
Ansgar> it is supposedly a "no-op") happens on a scale larger than
Ansgar> the entire sysvinit user base here...

Ansgar, you keep bringing this issue up.
And it keeps coming up as "Stuff might happen that we don't really
understand."

That's deeply unsatisfying to hear.
And I think it's deeply unsatisfying to you when you hear that people
talk about playing alternative games and assuming it's just going to
work out.

But this issue has kind of reached the level of FUD on both sides.
In that it's really hard to respond to "bad stuff might happen," and yet
you've also presented evidence that  there's something that needs to be
considered.

I think the way forward is to actually try and get people to explore
what the issues are and to write them up for all of us.

And once we've done that, assuming that we've done a credible job of
trying to research it, trust our conclusions.
Yeah, we might introduce bugs and have to revise those conclusions.
But saying "something bad might happen but we don't know what,"
is really frustrating to hear.

I do understand it's also frustrating when you keep bringing up a real
concern and it is dismissed.

have stron

If one of the options that promotes alternatives wins, I think it's
important to do this work.
I think the work would be valuable regardless of which option wins, but
especially if we're going to continue to support alternate init systems.

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Ansgar]

Adam Borowski writes:
>   * dependencies on "systemd | other" rather than "other | systemd"; this is
> a no-op on a systemd system (installed by debootstrap before any
> non-base packages) but causes apt to force an init+rc switch elsewhere

It's very likely not a no-op on systemd systems as significantly more
people somehow got systemd-shim installed than had sysvinit-core, see
for example [1] which shows that somehow the "no-op" results in
systemd-shim getting installed (which caused problems in the past).

Just because you don't observe unwanted behavior happening right now on
your system doesn't imply it doesn't exist.  And the unwanted behavior
that you say wouldn't happen (as it is supposedly a "no-op") happens on
a scale larger than the entire sysvinit user base here...

Your policykit-1 example would likely also suffer from this: adding
alternative builds doesn't only complicate packaging, but it makes the
dependency relations more complicated.  As we've seen from systemd-shim
it's hard to get this right (and Debian did not get this right); from
memory the policykit-1 dependencies to support alternatives looked more
complicated and fragile than what we had for systemd-shim, so they would
probably result in unwanted behavior more often.

So the policykit maintainers wanting to avoid these problems is
understandable to me (I don't think trying to force maintainers to
accept such patches via a GR (option D) is a good solution either).
It doesn't really help that you pretend that there are no issues with
complex dependencies (as above). At a certain point it doesn't make
sense to repeat saying that to you.

  [1]: 
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim_installed=on_legend=on=1

>   * recently added lintian warning requiring maintainers to add a redundant
> .service file even if an init script it already there.  It doubles the
> work and makes one of methods not maintainer-tested (some folks won't
> test init scripts, I won't test .service).  And in most cases doesn't
> even bring any good.

Having multiple init systems that all just call the same sysvinit script
without taking advantage that their native unit type (whatever it is)
provides seems rather uninteresting to me.  It would just mean we get
different implementations that in the end call the same init scripts (so
not "multiple implementations" at all).

What would be the point of providing, for example, openrc be then?

As you don't use systemd I also doubt you would know which (admittedly
mostly minor) annoyances exactly systemd's sysv-compat layer can cause
and would prefer if you didn't try to block people from improving
things.

Really, going back to a "should we really ship systemd units" discussion
makes me wish we would just drop sysvinit completely so we don't have to
restart any discussion from zero (or the point where any alternative
init system was added to Debian).

Ansgar

Re: My analysis of the proposals

[Wouter Verhelst]

On Mon, Dec 02, 2019 at 08:36:11PM +0200, Uoti Urpala wrote:
> On Mon, 2019-12-02 at 19:29 +0200, Wouter Verhelst wrote:
> > Sysvinit has worked for over 20 years. Yes, it has warts, but the warts
> 
> > I therefore disagree in the strongest terms to make this be about the
> > position of sysvinit, except in so far as it is part of an abstract
> > group of "not systemd" options that we are trying to decide upon.
> 
> I don't understand what point you're trying to make. My point was that
> what actual conflict there is, is in practice conflict between those
> who want to stay with sysvinit, and those who want to use systemd; and
> therefore the most practically important part of a resolution is how it
> would apply to sysvinit support. Your message first contains a defense
> of sysvinit, then a claim that "therefore" it should not be considered
> to be about sysvinit. I don't see how that "therefore" would logically
> follow.

I grant you that I could have quoted better. Allow me to try to do that
now.

You wrote, in a message upthread, the following:

> [...] I disagree: it's perfectly reasonable to consider sysv init
> scripts obsolete, and consider "try to keep sysvinit at 2014 levels
> indefinitely" activity a dead end.
> 
> Note that I'm not saying that people shouldn't develop alternatives to
> systemd. But to be taken seriously, they'd need to display some real
> progress beyond sysvinit (and Upstart). Just "this allows to boot
> without systemd" is not a worthwhile "alternative".

This to me framed the rest of what you wrote, also in later messages. I
should have replied to the above message rather than the later one, but
I guess I was not careful enough. Sorry about that.

Anyway, my point is that even if you think that sysvinit is now no
longer a valid option, that is an opinion that reasonable people could
disagree with.

For those who think that sysvinit is good enough, and that the problems
for which systemd provides a solution are not problems to begin with,
there is nothing wrong with the premise of "try to keep sysvinit at 2014
levels indefinitely", on the contrary. So, while it's a valid question
for Debian to decide whether to continue to support alternative
solutions to systemd, I don't think it's reasonable for someone who is
not involved with any of the alternatives to decide whether one of the
available options is valuable to begin with.

As such, I don't think, and vehemently disagree with your stated
proposal, that we should decide anything on sysvinit in particular,
other than through the more general question of "should Debian support
anything that is not systemd".

Thanks,

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Question Under Proposal D: Compile Time Option

[Ansgar]

Thomas Goirand writes:
> On 11/29/19 11:32 PM, Sam Hartman wrote:
>> Ian, I find  that I'm not able to answer Simon's question with regard to
>> Proposal D.
>>
>> Imagine that we have a program that has compile time support for systemd
>> and for other mechanisms.  It provides enhanced functionality when built
>> against systemd, but when so built, it cannot run without systemd.
>>
>> It's packaged that way in Debian.
>> Someone files a bug with a patch that changes the compilation option to
>> support the non-systemd bug, removing the enhanced systemd
>> functionality.
>>
>> What does proposal D say about this?
>> Is the package RC buggy under proposal D until this patch is applied?
>> Does the maintainer have the option to retain the enhanced
>> functionality?
>
> Sam,
>
> Is this a real life case (if so, please name the package...), or just a
> pure fictional one, just because you love debating?

Some people have suggested to do this for policykit-1 to support other
implementations than systemd-logind for some functions.

The policykit-1 maintainers did not want to do this as it complicates
packaging and, more importantly, package relationships (it's very hard
to get the right packages installed in some cases in Debian's dependency
system; see [1] for a related example).

Ansgar

  [1] 
https://qa.debian.org/popcon-graph.php?packages=sysvinit-core+systemd-shim_installed=on_legend=on=1

Re: My analysis of the proposals

[Uoti Urpala]

On Mon, 2019-12-02 at 19:29 +0200, Wouter Verhelst wrote:
> Sysvinit has worked for over 20 years. Yes, it has warts, but the warts

> I therefore disagree in the strongest terms to make this be about the
> position of sysvinit, except in so far as it is part of an abstract
> group of "not systemd" options that we are trying to decide upon.

I don't understand what point you're trying to make. My point was that
what actual conflict there is, is in practice conflict between those
who want to stay with sysvinit, and those who want to use systemd; and
therefore the most practically important part of a resolution is how it
would apply to sysvinit support. Your message first contains a defense
of sysvinit, then a claim that "therefore" it should not be considered
to be about sysvinit. I don't see how that "therefore" would logically
follow.

Re: My analysis of the proposals

[Russ Allbery]

I should say up front that I'm not also replying to Uoti along the same
lines only because Sam and Wouter already have.

Simon Richter  writes:

> Systemd has reached a level of complexity where debugging failures is a
> specialized skill set rather than just application of generic shell
> script knowledge and a few simple design concepts. The promised "flatter
> learning curve" got appended at the bottom of the mountain and only
> increased the total height. There is a nice plateau there though.

> Effectively we now have a new class of user that knows a set of magic
> incantations to make a piece of black box software behave, but cannot
> repair problems outside of that.

> Twenty years ago, we used to make fun of people who crammed system
> administration recipes for their MCSE exams instead of learning how the
> system worked so they could derive them on the spot like we did on Unix.
> Thing is, that was impossible on Windows then, and it is impossible with
> systemd now, because the actual implementation is complex and very much
> in flux.

This sort of presentation is a good example of the kinds of social
problems that always surface in this debate.  I realize that you were
provoked, which also wasn't okay, but I hope that in re-reading these
three paragraphs you can see how insulting it is to those who prefer to
use systemd, and how it serves as bait for systemd users to defend their
choice against what they see as unfair and inaccurate criticism.

You may not *like* how debugging systemd works, and you may believe that
it is much more complex or uses systemd-specific instead of general
skills.  Many other people *do not agree with you*.  Stating these
opinions as if they're uncontrovertible facts contributes to emotional
burnout and makes Debian a less enjoyable project to interact with.
Please acknowledge that you could be wrong, and that other equally
intelligent and thoughtful members of the project have arrived at
different conclusions.

We were doing so well in this thread in staying away from reiterating
these aggressive and insulting arguments about each other's preferences,
and then Uoti dug up a common line of attack and baited you into making
the rote response.  Please don't.

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

Re: My analysis of the proposals

[Wouter Verhelst]

On Mon, Dec 02, 2019 at 03:59:58AM +0200, Uoti Urpala wrote:
> On Sun, 2019-12-01 at 18:43 -0500, Sam Hartman wrote:
> > > > > > > "Uoti" == Uoti Urpala  writes:
> > 
> > Uoti> IMO encouragement for supporting alternative systems could be
> > Uoti> reasonable, but only for actual new innovation; maintainers
> > Uoti> should be explicitly permitted to remove any existing sysvinit
> > Uoti> scripts and refuse addition of similar scripts. Systemd units
> > Uoti> should be no worse a basis to bootstrap a new system.
> > 
> > 
> > This is what I tried to capture with Proposal B.
> > I wrote a blog post yesterday which still should be on planet discussing
> > my thoughts about this and discussing some of the risks of that
> > proposal.
> 
> Based on your blog post, your technological views seem similar to mine.
> Where my view differs, and why I think Proposal B is not particularly
> satisfactory, is more about the social view of opposition to systemd.
> 
> Like you, I think that from a technological point of view you shouldn't
> assume that those who want alternatives to systemd would support
> sysvinit. However, as a matter of social reality, people who oppose
> systemd almost exclusively do want to keep using sysvinit. People who
> find systemd objectionable mostly just don't want to switch to it,
> without really caring about whether their current setup is a
> technological dead end or not.

While I prefer systemd on my personal systems, I don't think this
framing is in any way correct or fair.

Sysvinit has worked for over 20 years. Yes, it has warts, but the warts
are well-known and can fairly easily be dealt with. More importantly,
the concept of how sysvinit works ("here's a bunch of scripts that are
executed" is at a certain level easier to grasp than systemd's concepts.

You may be of the opinion that systemd is strictly and obviously better,
but that is a judgment call, one which reasonable people may disagree
with. There is nothing wrong with being of the opinion that booting with
sysvinit is easier to grasp and preferable over using systemd. It is
therefore still a valid alternative for as long as Debian does not make
the use of systemd mandatory.

I therefore disagree in the strongest terms to make this be about the
position of sysvinit, except in so far as it is part of an abstract
group of "not systemd" options that we are trying to decide upon.

-- 
To the thief who stole my anti-depressants: I hope you're happy

  -- seen somewhere on the Internet on a photo of a billboard

Re: Question Under Proposal D: Compile Time Option

[Sam Hartman]

> "Thomas" == Thomas Goirand  writes:

Thomas> Sam,

Thomas> Is this a real life case (if so, please name the
Thomas> package...), or just a pure fictional one, just because you
Thomas> love debating?

Thomas> Cheers,

So, first of all, note that this question has already been adequately
answered:
* the significant effect on systemd installations criteria is the
biggest consideration
*  compiling twice  or turning into runtime configuration are the
biggest mittigation.

I had at least two situations in mind: Gnome (say policykit) and
libvert.
They are a bit different.

I think your tone is overly confrontational.
based on several previous messages, it was clear at the time I wrote the
message that it was a real issue.
Ian knew that; Simon knew that.
Someone else came along and gave a great response (talking about
compiling twice).
Ian pointed out that I'd missed the significant effect on non-systemd
systems criteria, which was helpful to me.  I regret missing that
detail, but these issues are complex enough we all make mistakes from
time to time.

Basically several of us all assumed good faith of each other and had a
great discussion.
You come along a couple of days later and imply that I might not have
been acting in good faith and make Debian just a little less nice to be
in.
Please don't.

Re: Question Under Proposal D: Compile Time Option

[Neil McGovern]

On Mon, Dec 02, 2019 at 05:18:35PM +0100, Thomas Goirand wrote:
> On 11/29/19 11:32 PM, Sam Hartman wrote:
> > Imagine that we have a program that has compile time support for systemd
> > and for other mechanisms.  It provides enhanced functionality when built
> > against systemd, but when so built, it cannot run without systemd.
> > 
> Is this a real life case (if so, please name the package...), or just a
> pure fictional one, just because you love debating?
> 

Or a hypothetical one, but one which could be fairly reasonable to
expect. This GR seems to be trying to put in place a statement on what
exactly we mean by support, and so considering things which may
reasonably happen in the future is something that we should do.

I don't find your phrasing as a binary choice useful, and ascribing
motives to Sam seems disingenuous.

Neil
-- 


signature.asc
Description: PGP signature

Re: Question Under Proposal D: Compile Time Option

[Thomas Goirand]

On 11/29/19 11:32 PM, Sam Hartman wrote:
> 
> Ian, I find  that I'm not able to answer Simon's question with regard to
> Proposal D.
> 
> Imagine that we have a program that has compile time support for systemd
> and for other mechanisms.  It provides enhanced functionality when built
> against systemd, but when so built, it cannot run without systemd.
> 
> It's packaged that way in Debian.
> Someone files a bug with a patch that changes the compilation option to
> support the non-systemd bug, removing the enhanced systemd
> functionality.
> 
> What does proposal D say about this?
> Is the package RC buggy under proposal D until this patch is applied?
> Does the maintainer have the option to retain the enhanced
> functionality?

Sam,

Is this a real life case (if so, please name the package...), or just a
pure fictional one, just because you love debating?

Cheers,

Thomas Goirand (zigo)

Re: Proposal: Reaffirm our commitment to support portability and multiple implementations

[Simon McVittie]

On Mon, 02 Dec 2019 at 04:26:53 +0100, Simon Richter wrote:
> My expectation was that with systemd, dbus activation functionality
> would have moved into the main systemd binary for better process
> tracking and to avoid code duplication with the other activation methods.

Yes ish, but on an opt-in basis (the D-Bus service integration file has to
refer to the corresponding systemd unit file via the SystemdService key).
Many (most?) system services and some session/user services do this.

For session/user services, this is only done when dbus-user-session is
in use - otherwise, the scope of the dbus-daemon and the scope of
`systemd --user` would be different, making it inappropriate to turn
D-Bus services into systemd user services.

On a systemd system, running systemd-cgls will show you which D-Bus
services have been delegated to systemd (they have their own cgroup
alongside dbus.service) and which ones have not (they are part of
the same cgroup as dbus-daemon).

smcv