Bug#132542: sysvinit: please make /etc/init.d/rcS a conffile

[Pierre Ynard]

> That's not what my argument is -- what I mean, is that there's many
> more components that need to stick strictly to files not on /usr
> during that phase of the boot, sysv-rc being only a single one.
> Efforts to keep it working are a waste of time, not because you won't
> get to simplify things, but because you would need to override a
> number of other maintainers.

No. I think what you're saying is backwards. My opinion is that what
really creates a waste of time, is all the maintainers and packages
launching a deliberate effort to shift files around to serve the /usr
merge cause. Just don't break it in the first place, and then there will
be no waste of time trying to keep it unbroken.

Also, sysv-rc is not "only a single" component, it's a critical MAJOR
boot component.

> Simple setups still work in Buster, but it's easy to run into
> something that doesn't. That'd be a nasty surprise for the user, thus
> it's better to make the break faster and more obvious.

Oh, so you're explaining that a situation falling short of ideal is
nasty, and also breaking things is good, especially breaking things for
the sake of clearly driving the point that they're broken.

What was I saying earlier again?

> This is the classic systemd philosophy argument that if portability
> cannot be fully guaranteed, it is counterproductive and harmful and
> ought to be eliminated.

> Personally I think it's quite a perversion of common software
> standards to reach a point where portability efforts are frowned upon
> and discouraged.

> Just stop that self-fulfilling prophecy, and it will work better.

> just not choosing the one option that deliberately breaks more stuff
> for the sake of establishing clearly what is broken and what isn't
> according to a controversial ideology.

I rest my case. Clearly we have very different opinions about software
development standards and responsibility for your work and to your
users. I just hope Debian will continue to uphold the values for which
I've been with it.

> Then, pretty surely even such simple setups won't work in Bullseye.

Does that mean that there are already plans to expand for Bullseye the
scope and clarity of that breakage ideology?

> There's a cost to migrations like this: any move may break stuff.
> There's an easy way for Buster: just drop the move, it serves no need.

The files have already been moved again to /lib/init. Is there an
assumption that they will have to be moved again away from /lib after
Buster?

Once again, simple setups, or any kind of setup still working is good.
Freedom and possibilities for the users to tweak their software into
what they choose, and to fix and improve their software to suit their
needs, is good. Please don't say things that feel as if users and use
cases that don't conform to a given ideology are better off rooted out.

-- 
Pierre Ynard