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

[Pierre Ynard]

> > udev (not even original systemd software) [...] (and unlike init,
> > there's no alternative to it)
>
> The Devuan people would like to introduce you to vdev
> .
>
> Laurent Bercot would like to introduce you to mdevd
> .
>
> I have service bundles for four different Linux plug-and-play managers
> 
> in the nosh toolset.

Yes, thank you for clarifying this!

Personally I really don't have much of a use case for plug-and-play.
Rather, the way I look at it is how to avoid unwanted components that
get pulled on my system. And unfortunately as far as I can see, none
of these alternatives are packaged in Debian, and more importantly,
packages like xserver-xorg-core for example declare a hard dependency on
udev with no alternative mechanism.

If you want to know, these alternatives are something I suggested in my
udev rant: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=827704 You
can see where that went.

> Almost everything in *lots* of pseudo-user directories under /usr was
> the actual classical Unix way.

And there's also the pattern of packages installing their files into
their own private hierarchy under /opt/// ... much
like what happens under \Program Files\ on Microsoft Windows, the
rationale being, it's well-suited to avoid collisions without central
coordination.

Regards,

-- 
Pierre Ynard

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

[Jonathan de Boyne Pollard]

Thorsten Glaser:

> Just accept that this idea, originating from the systemd people at 
Fedora/Freedesktop, is NOT welcome to classical Unix people.


Ahem!  We classical Unix people experienced this idea in the late 1980s, 
from where it *really* originated, Sun and AT


* https://groups.google.com/d/msg/comp.sys.sun/K9286yRtZ8c/Abwzdo05gMMJ

The separate /sbin that you are asserting to be classical Unix and 
suggesting as the place to put things here, actually was not classical 
Unix in the first place.  Sun's Rusty Sandberg is credited with 
inventing the ideas of /var and /sbin which the world gained with SunOS 
4.0 in 1988, a year before AT System 5 Release 4 put it into /usr as 
/usr/sbin with only a symbolic link at /sbin, and two years before 
4.3BSD Reno adopted it in 1990, the BSD world having to that point used 
/etc for such binaries.  Having things in lots of directories under /usr 
(/usr/amdahl/bin, /usr/ucb, /usr/5bin, /usr/3bin, /usr/eun, 
/usr/stanford/bin, /usr/brl, /usr/bbn, /usr/jerq/bin, and so on) 
*pre-dates* the very idea of /sbin on Unix and was how things were for 
most of the 1980s and the 1970s.


* 
https://groups.google.com/d/msg/comp.unix.questions/g9DsvKQx8h8/QNs0F-mHpR4J


* https://unix.stackexchange.com/a/448799/5132

* https://groups.google.com/d/msg/comp.unix.wizards/pLc_jhCUDtU/WD92a732Nx4J

Almost everything in *lots* of pseudo-user directories under /usr was 
the actual classical Unix way.

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

[Jonathan de Boyne Pollard]

Pierre Ynard:

> udev (not even original systemd software) [...] (and unlike init, 
there's no alternative to it)


The Devuan people would like to introduce you to vdev 
.


Laurent Bercot would like to introduce you to mdevd 
.


I have service bundles for four different Linux plug-and-play managers 
 in 
the nosh toolset.

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

[Thorsten Glaser]

On Sun, 20 Jan 2019, Adam Borowski wrote:

> 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. Then, pretty
> surely even such simple setups won't work in Bullseye.

That’s completely backwards.

I’d expect people with such setups to report in when they have
any problems (perhaps even on unstable, but I know the corporate
world), but if things work for them, they don’t need to, and if
they break they’ll notice that on their test setup (hopefully)
and can act appropriately.

By keeping the officially unsupported thing possible we’re sen‐
ding a signal that patches to fix what was accidentally broken
are welcome, even for officially unsupported scenarios that need
a little local admin love to work.

(Incidentally, I was very angry at the bash/dash maintainers
when they broke the old way to use mksh as /bin/sh, which was
rather easy, by changing the way the diversions and symlinks
were distributed. And Policy actually does support running a
system with lksh (from the mksh package) as /bin/sh…)

I like the “my beautiful little paradise” analogy and postu‐
late that many experienced Debian users have those little
paradises of their own, which is why I’m going to continue
to push for freedom of choice, and upstreaming as much of
that as possible so that that freedom of choice is not only
in theory possible but also practical (from amount of devia‐
tions from stock needed).

Thanks for listening,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

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

[Thorsten Glaser]

On Sat, 19 Jan 2019, Pierre Ynard wrote:

> "screw this", and copy the files they need by hand, out of packaging,
> back into /lib or /bin. Then other people will reply: "They're shooting

Nah, dpkg-divert is the right tool for that.

.oO(did I just confirm that “some people” exist? oops…)

bye,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

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

[Thorsten Glaser]

On Sat, 19 Jan 2019, KatolaZ wrote:

> > But you did not answer real question -- what are benefits of separate /
> > and /usr without initramfs? As I already mentioned, two-stage mount
> > complicates things. For what?
> 
> Since you decided to go there: what are the benefits of forbidding it,

Exactly.

The split /usr is, as I said, not a setup I’d run myself, but I can
see people using it, especially on machines upgraded from, say, slink.
Running without initramfs also has its uses. Remember that Debian
is not just used “out of the box” on a desktop, but also in highly
specialised embedded appliances upgraded once in a full moon (perhaps
more often with security fixes, one would hope), in remote locations
(which means upgrading must not fail as nobody has local access to
the hardware), and with historical constraints on system layout.

I mean, look at this:

-rw-r--r-- 1 root root 29197586 Jan 10 17:51 initrd.img-4.19.0-1-amd64
-rw-r--r-- 1 root root  5172512 Dez 30 10:04 vmlinuz-4.19.0-1-amd64

That’s bordering on insane, size-wise.

> if any? I know it is currently not supported in Debian, but so far
> sysadmins have the possibility of getting it to work, if they like,
> and with relatively little effort. If we keep pushing more and more

Exactly that. While it is not “officially” supported “out of the box”
we should not take that as a licence to make it more and more diffi‐
cult for those that *did* the extra step of letting it work in their
specific scenarios.

The pro-initramfs arguments are plug and play hardware, dynamic de‐
vice numbers, etc. but these often don’t apply to embedded appliances
(which is why I postulated that, on *some* systems, split /usr with‐
out initramfs MIGHT even work out-of-the-box on Debian… modulo the
kernel configuration, of course, but while I’m not running a custom
kernel on Debian, many do).

Thanks,
//mirabilos
-- 
«MyISAM tables -will- get corrupted eventually. This is a fact of life. »
“mysql is about as much database as ms access” – “MSSQL at least descends
from a database” “it's a rebranded SyBase” “MySQL however was born from a
flatfile and went downhill from there” – “at least jetDB doesn’t claim to
be a database”  ‣‣‣ Please, http://deb.li/mysql and MariaDB, finally die!

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

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

[Adam Borowski]

On Sat, Jan 19, 2019 at 07:34:26PM +, Dmitry Bogatov wrote:
> [2019-01-18 02:20] Adam Borowski 
> > That ship has long since sailed.  What's the point of making sysv-rc support
> > non-/usr early boot if the rest of the system doesn't?  It may still work on
> > some simple installs, but even that quite rapidly degrades as random
> > packages get changed to simplify this away.
> 
> The same argument could be applied to many other things: systemd,
> web-2.0, html emails, MS Office, GitLab/Hub. Still, I use runit init
> system, text browser, text mail client and still send patches via
> git-send-email.
> 
> I object when someone appears and try break my beautiful little
> paradise.  And I definitely do not want to come and break someone's
> else.

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.

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.  Then, pretty surely even such simple
setups won't work in Bullseye.

> > >   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
> > >   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
> > >   mounted at /sbin/init invocation in Buster. I promise.
> > 
> > That's a waste of your time.  Both for and after Buster.
> 
> That is being responsible to my users. I do not consider it waste.

There's a cost to migrations like this: any move may break stuff.  For
example, it breaks that silly little init I used to have in my .sig (and
included in this mail), but people may refer to that file for reasons other
than mere fun.

There's an easy way for Buster: just drop the move, it serves no need.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀ .globl _start↵.data↵rc: .ascii "/etc/init.d/rcS\0"↵.text↵_start
⣾⠁⢰⠒⠀⣿⡁ mov $57,%rax↵syscall↵cmp $0,%rax↵jne child↵parent:↵mov $61,%rax
⢿⡄⠘⠷⠚⠋⠀ mov $-1,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall↵jmp parent↵child:
⠈⠳⣄ mov $59,%rax↵mov $rc,%rdi↵xor %rsi,%rsi↵xor %rdx,%rdx↵syscall

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

[KatolaZ]

On Sat, Jan 19, 2019 at 07:34:25PM +, Dmitry Bogatov wrote:
> 
> [2019-01-18 14:32] Thorsten Glaser 
> >  * what are your arguments aganist usrmerge?
> > 
> > Please let’s not go there. Just accept that this idea, originating
> > from the systemd people at Fedora/Freedesktop, is NOT welcome to
> > classical Unix people.
> 
> Adam correctly pointed in his email, that usrmerge is off the topic.
> I will not go there.
> 
> But you did not answer real question -- what are benefits of separate /
> and /usr without initramfs? As I already mentioned, two-stage mount
> complicates things. For what?

Since you decided to go there: what are the benefits of forbidding it,
if any? I know it is currently not supported in Debian, but so far
sysadmins have the possibility of getting it to work, if they like,
and with relatively little effort. If we keep pushing more and more
stuff under /usr for no reason except the (quite feeble) ones
purported so far in debian-devel, we will make the prophecy become
automatically true.

There is no reason to make the life of "unaligned" sysadmins any
harder than it is now. The fact that you can't see a use case does not
mean that you should do anything in your power to make it impossible.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

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

[Dmitry Bogatov]

[2019-01-18 14:32] Thorsten Glaser 
>  * what are your arguments aganist usrmerge?
> 
> Please let’s not go there. Just accept that this idea, originating
> from the systemd people at Fedora/Freedesktop, is NOT welcome to
> classical Unix people.

Adam correctly pointed in his email, that usrmerge is off the topic.
I will not go there.

But you did not answer real question -- what are benefits of separate /
and /usr without initramfs? As I already mentioned, two-stage mount
complicates things. For what?

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

[Dmitry Bogatov]

[2019-01-18 02:20] Adam Borowski 
> > Wow. So strong reaction. Fine. Collegues, I understand your attitude.
> > You have some setup, with separate / and /usr, without initramfs, and
> > you do not want change anything.
>
> That ship has long since sailed.  What's the point of making sysv-rc support
> non-/usr early boot if the rest of the system doesn't?  It may still work on
> some simple installs, but even that quite rapidly degrades as random
> packages get changed to simplify this away.

The same argument could be applied to many other things: systemd,
web-2.0, html emails, MS Office, GitLab/Hub. Still, I use runit init
system, text browser, text mail client and still send patches via
git-send-email.

I object when someone appears and try break my beautiful little
paradise.  And I definitely do not want to come and break someone's
else.

> >   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
> >   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
> >   mounted at /sbin/init invocation in Buster. I promise.
> 
> That's a waste of your time.  Both for and after Buster.

That is being responsible to my users. I do not consider it waste.

> >  * what are your arguments aganist usrmerge?
> I'd reverse the question: what are your arguments _for_ usrmerge?
> Its proponents tend to conflate dropping early non-/usr boot
> with symlinking /bin + /sbin + /lib.

If we dismiss two-stage mount (ship sailed, as you claim), having two
separate locations for binaries is not logical.  If you want to discuss
usrmerge further, please move to another list (or, if you wish, send in
private).

But, as you correctly mentioned, we are discussing early non-/usr boot
here.

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

[Pierre Ynard]

> Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will
> be in 2.93-4 (due in few days). Sysvinit will *not* assume, that
> /usr is mounted at /sbin/init invocation in Buster. I promise.

Thank you.

> That ship has long since sailed. What's the point of making sysv-rc
> support non-/usr early boot if the rest of the system doesn't?

This is the classic systemd philosophy argument that if portability
cannot be fully guaranteed, it is counterproductive and harmful and
ought to be eliminated. Then it leads to absurd, complete reversals of
how things should be, such as udev (not even original systemd software)
imposing requirements on the kernel on any system where it's pulled
in (and unlike init, there's no alternative to it). Never mind that
"support" and "fully guaranteed" are fuzzy concepts whose goal posts can
be adjusted by the authority telling us what should be done. Personally
I think it's quite a perversion of common software standards to reach a
point where portability efforts are frowned upon and discouraged.

> It may still work on some simple installs, but even that quite rapidly
> degrades as random packages get changed to simplify this away.

It degrades as random packages get pushed into alignment with the
simplified state that systemd wants to achieve, which is itself based
on eliminating "harmful" portability. Just stop that self-fulfilling
prophecy, and it will work better.

> If someone insists to pretend / vs /usr on separate fs without initramfs
> would be supported for Buster

No, I don't think anybody is aiming at "pretending" "support". I think
what people are talking about here is just not breaking stuff, just not
choosing the one option (talking about the location of two files here)
that deliberately breaks more stuff for the sake of establishing clearly
what is broken and what isn't according to a controversial ideology.
Please don't make it sound like they are pretending things that you're
shooting down.

> But what next? Assumption of mounted /usr simplify things. You can
> take a look at #551555, but I do not think this is singular case.

First, #551555 is trying to solve a real problem with supporting many
different configurations; whereas putting init files on /usr solves and
supports nothing, it just potentially breaks things.

Assuming that /usr is mounted is one way to approach #551555; but
assuming that /usr isn't on NFS, or that mountnfs.sh won't need DNS,
would also simplify things - and would be less pervasive options. That
still doesn't mean they're good ideas. Of course, the only assumption
that could already be provided by a system-wide decision from the Debian
project when you start looking at this particular problem, is the /usr
one; so the solutions are skewed, but at least there is that option.

> Two-part mount process complicates initscripts for, well, what?

Note that the proposed solution to #551555 still requires shifting many
packages from rcS.d to rc2.d. Bootstrapping /usr is still a complicated
problem if you don't know in advance which set of tools and scripts will
need to do it.

Personally, I'm not talking about a two-part mount process. My
systems boot fine with a single mount pass, and so do plenty other
rationally designed boot setups mindful of that. If you leave them easy
possibilities, users can still tweak dependencies and scripts to get
their boot sequence just right.

And if anything, booting from initramfs then pivoting to / is the
two-part process I would personally try to avoid.

>   * what are benefits of setup without initramfs *and* with separate /usr
>   partition on *fresh installation*?

This systemd opinion itself names plenty of benefits for a separate /usr:
https://www.freedesktop.org/wiki/Software/systemd/TheCaseForTheUsrMerge/
These benefits are what /usr merge is trying to improve, further and
complete. The ideas behind them don't really relate to initramfs or
whether the installation is fresh.

> That you may hop onto a time machine with a modern install media but
> no modern hardware? I'm not aware of any widespread machines that
> have ~2GB of fast local storage with the rest separate. If there's a
> separate boot media, it tends to have up to ~256MB tops, fit only for
> the kernel and bootloader.

Wrong, 256MB is quite enough for my whole separate /, not just kernel
and bootloader.

> Around a decade ago, Nokia installed _tiny_ boot disk and large eMMC into
> N{7,8,9}00, but even then they found / vs /usr to be useless, and concocted
> their own scheme.  Same happens for other setups from this millenium.

You've mentioned one specialized use case that didn't find interest in
a separate /usr. So what, what have you proven? I've worked too on some
deployment setups that had no benefit in separate partitioning, that
doesn't mean it's pointless in every case. The reasons are diverse and
the most interesting ones to me are other than hardware size.

> If someone could show us a case when early 

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

[Thorsten Glaser]

On Fri, 18 Jan 2019, KatolaZ wrote:

> > FHS uses term "binaries". I believe scripts qualify too, since /lib is

I believe that s/binaries/executables/ applied to FHS helps interpreting.

> >  * what are your arguments aganist usrmerge?

Please let’s not go there. Just accept that this idea, originating
from the systemd people at Fedora/Freedesktop, is NOT welcome to
classical Unix people.

> /etc/init.d, or, maybe better, let's put it under /bin, and link it

No, not /bin. If it must be in one of these, /sbin would apply,
but I’d personally say /lib/init/ is a good place except if the
local administrator is supposed to change them.

> from /etc/init.d. After all, it's an executable that is needed at boot
> time, so having it under /bin looks totally right, and linking it from

/bin is also supposed to be in the normal user’s path. libexec
sounds the most right, but AIUI we don’t have that under / and
for just two more files, /lib/init/ (which already exists and
contains stuff needed for initscripts) does the job just fine.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

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

[KatolaZ]

On Thu, Jan 17, 2019 at 09:28:38PM +, Dmitry Bogatov wrote:
> 
> [2019-01-15 17:35] Thorsten Glaser 
> > On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
> >
> > > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 
> > > 2014):
> >
> > The latter is okay for systems booted with initramfs. But I
> > recall that it was decided some not too long time ago that
> > people not using it should ensure their /usr is available
> > by themselves.
> >
> > I do not agree with usrmerge, and I fully expect to be able
> > to use Debian without that systemd-originating concept.
> >
> > But I agree it’s “probably” late enough, although nice to be
> > considerate to people whose systems aren’t.
> 
> > [Pierre Ynard]
> > Also, what is the policy about /usr/libexec/ regarding
> > architecture-dependent and -independent executables?
> 
> FHS uses term "binaries". I believe scripts qualify too, since /lib is
> explicitly for "shared libraries and kernel modules".  Installation of
> {rc, rcS} into either /lib or /etc is violation of FHS.
> 
> > [Pierre Ynard]
> > My personal feelings here would be similar to Thorsten's, but what I
> > would put forward is that considering how critical a component of the
> > system init is, perhaps it's best to strive for robustness for now.
> 
> Wow. So strong reaction. Fine. Collegues, I understand your attitude.
> You have some setup, with separate / and /usr, without initramfs, and
> you do not want change anything.
> 
>   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
>   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
>   mounted at /sbin/init invocation in Buster. I promise.
> 
> But what next? Assumption of mounted /usr simplify things.  You can take
> a look at #551555, but I do not think this is singular case. Two-part
> mount process complicates initscripts for, well, what?
> 
> I do understand dislike of initramfs, but I do not understand why
> separate / and /usr. So,
> 
>  * what are benefits of setup without initramfs *and* with separate /usr
>partition on *fresh installation*?
>  * what are your arguments aganist usrmerge?
> 
> PS. No offense intended to anybody. Sorry, if my previous emails felt
> rude.
> 

I don't think this is the place to discuss the pros and cons of
separate / and /usr, TBH. And at this point in time is not even so
straightforward to "assume a mounted /usr", IMHO.

If we cannot put the script under /lib/init, let's leave it under
/etc/init.d, or, maybe better, let's put it under /bin, and link it
from /etc/init.d. After all, it's an executable that is needed at boot
time, so having it under /bin looks totally right, and linking it from
/etc/init.d helps avoiding unexpected breakages upon upgrades.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

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

[Adam Borowski]

On Thu, Jan 17, 2019 at 09:28:38PM +, Dmitry Bogatov wrote:
> > [Pierre Ynard]
> > My personal feelings here would be similar to Thorsten's, but what I
> > would put forward is that considering how critical a component of the
> > system init is, perhaps it's best to strive for robustness for now.
> 
> Wow. So strong reaction. Fine. Collegues, I understand your attitude.
> You have some setup, with separate / and /usr, without initramfs, and
> you do not want change anything.

That ship has long since sailed.  What's the point of making sysv-rc support
non-/usr early boot if the rest of the system doesn't?  It may still work on
some simple installs, but even that quite rapidly degrades as random
packages get changed to simplify this away.

>   Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
>   in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
>   mounted at /sbin/init invocation in Buster. I promise.

That's a waste of your time.  Both for and after Buster.

If someone insists to pretend / vs /usr on separate fs without initramfs
would be supported for Buster, I strongly recommend to revert that commit
for now, then move to a final position after Buster.  Any such transition is
risky, failures causing a machine to be unbootable, thus the cost of moving
twice is nasty.

> But what next? Assumption of mounted /usr simplify things.  You can take
> a look at #551555, but I do not think this is singular case. Two-part
> mount process complicates initscripts for, well, what?

I have yet to hear any use case.

> I do understand dislike of initramfs, but I do not understand why
> separate / and /usr. So,
> 
>  * what are benefits of setup without initramfs *and* with separate /usr
>partition on *fresh installation*?

That you may hop onto a time machine with a modern install media but no
modern hardware?  I'm not aware of any widespread machines that have ~2GB of
fast local storage with the rest separate.  If there's a separate boot
media, it tends to have up to ~256MB tops, fit only for the kernel and
bootloader.  / can then sit on the same place as /usr.

Around a decade ago, Nokia installed _tiny_ boot disk and large eMMC into
N{7,8,9}00, but even then they found / vs /usr to be useless, and concocted
their own scheme.  Same happens for other setups from this millenium.

Another case: this cookie box I'm typing these words on:
https://angband.pl/tmp/rockcipa/cookies.jpg

It needs a SD card to boot before the NVME can be accessed.  You don't
really get SD cards below 16GB these days (and if you do, they're really
slow).  The whole system can comfortably fit on the SD card, but then, I
for some reason prefer /bin and /var to sit on the NVME rather than SD.

If someone could show us a case when early non-/usr boot makes sense, I'm
all ears.

>  * what are your arguments aganist usrmerge?

I'd reverse the question: what are your arguments _for_ usrmerge?  On the
lengthy flamewars on debian-devel I haven't heard any.  It moves files
around for no gain, actively breaking important things like building
packages.  Its proponents tend to conflate dropping early non-/usr boot
with symlinking /bin + /sbin + /lib.


Meow!
-- 
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁ Remember, the S in "IoT" stands for Security, while P stands
⢿⡄⠘⠷⠚⠋⠀ for Privacy.
⠈⠳⣄

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

[Dmitry Bogatov]

[2019-01-15 17:35] Thorsten Glaser 
> On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
>
> > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 
> > 2014):
>
> The latter is okay for systems booted with initramfs. But I
> recall that it was decided some not too long time ago that
> people not using it should ensure their /usr is available
> by themselves.
>
> I do not agree with usrmerge, and I fully expect to be able
> to use Debian without that systemd-originating concept.
>
> But I agree it’s “probably” late enough, although nice to be
> considerate to people whose systems aren’t.

> [Pierre Ynard]
> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

FHS uses term "binaries". I believe scripts qualify too, since /lib is
explicitly for "shared libraries and kernel modules".  Installation of
{rc, rcS} into either /lib or /etc is violation of FHS.

> [Pierre Ynard]
> My personal feelings here would be similar to Thorsten's, but what I
> would put forward is that considering how critical a component of the
> system init is, perhaps it's best to strive for robustness for now.

Wow. So strong reaction. Fine. Collegues, I understand your attitude.
You have some setup, with separate / and /usr, without initramfs, and
you do not want change anything.

  Okay. I moved {rc, rcS} to /lib (see commit 51170798), change will be
  in 2.93-4 (due in few days). Sysvinit will *not* assume, that /usr is
  mounted at /sbin/init invocation in Buster. I promise.

But what next? Assumption of mounted /usr simplify things.  You can take
a look at #551555, but I do not think this is singular case. Two-part
mount process complicates initscripts for, well, what?

I do understand dislike of initramfs, but I do not understand why
separate / and /usr. So,

 * what are benefits of setup without initramfs *and* with separate /usr
   partition on *fresh installation*?
 * what are your arguments aganist usrmerge?

PS. No offense intended to anybody. Sorry, if my previous emails felt
rude.

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

[Thorsten Glaser]

On Thu, 17 Jan 2019, Pierre Ynard wrote:

> Also, what is the policy about /usr/libexec/ regarding
> architecture-dependent and -independent executables?

We can use multiarch subdirectories, the same as in /usr/lib/,
for example /usr/libexec/x86_64-linux-gnux32/ for x32. That
was announced when Policy changed.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

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

[Pierre Ynard]

My personal feelings here would be similar to Thorsten's, but what I
would put forward is that considering how critical a component of the
system init is, perhaps it's best to strive for robustness for now.

Also, what is the policy about /usr/libexec/ regarding
architecture-dependent and -independent executables?

-- 
Pierre Ynard

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

[KatolaZ]

On Tue, Jan 15, 2019 at 05:35:46PM +0100, Thorsten Glaser wrote:
> On Tue, 15 Jan 2019, Dmitry Bogatov wrote:
> 
> > As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> > coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 
> > 2014):
> 
> The latter is okay for systems booted with initramfs. But I
> recall that it was decided some not too long time ago that
> people not using it should ensure their /usr is available
> by themselves.
> 
> I do not agree with usrmerge, and I fully expect to be able
> to use Debian without that systemd-originating concept.
> 
> But I agree it’s “probably” late enough, although nice to
> be considerate to people whose systems aren’t.
> 

I would second Thorsten's remark. Let's avoid to be harsh, if there is
no reason about it.

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

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

[Thorsten Glaser]

On Tue, 15 Jan 2019, Dmitry Bogatov wrote:

> As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
> coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 
> 2014):

The latter is okay for systems booted with initramfs. But I
recall that it was decided some not too long time ago that
people not using it should ensure their /usr is available
by themselves.

I do not agree with usrmerge, and I fully expect to be able
to use Debian without that systemd-originating concept.

But I agree it’s “probably” late enough, although nice to
be considerate to people whose systems aren’t.

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

[Dmitry Bogatov]

[2019-01-13 17:10] Thorsten Glaser 
> On Sun, 13 Jan 2019, Pierre Ynard wrote:
> 
> > You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> > /lib/init/ ?...
> 
> /usr/libexec/ is now allowed on Debian, but anything under /usr
> does not seem to be the right place for things used by init,
> unless these are late enough that /usr is always mounted when
> they are used.

As far as I can tell, /sbin/init invocation is late enough.  Usrmerge is
coming. /usr is mounted by initramfs since initramfs-tools=0.117 (25 Sep 2014):

* Mount /usr if present in the /etc/fstab on the mounted rootfs
  (Closes: #652459)

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

[Dmitry Bogatov]

[2019-01-13 08:31] Pierre Ynard 
> Hello, and thanks a lot for your work on the sysvinit package!

I am happy to know, that this work is important not only to me.

> >* Move /etc/init.d/{rc,rcS} scripts out of /etc, retaining
> >  symbolic link for compatibility (Closes: #132542)
> 
> https://salsa.debian.org/debian/sysvinit/commit/0766e7195229ee5563bc4ff3b6bf0a4b350c780d
> 
> > +debian/src/sysv-rc/rc  /usr/libexec/sysvinit
> > +debian/src/sysv-rc/rcS /usr/libexec/sysvinit
> 
> You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> /lib/init/ ?...

Luckily, it does exists. Since recent Debian Policy (4.1.5?), Debian at
last adopted FHS-3.0, which have /usr/libexec:

$ dpkg -L debian-policy
[...]
/usr/share/doc/debian-policy/fhs
/usr/share/doc/debian-policy/fhs/fhs-3.0.html
/usr/share/doc/debian-policy/fhs/fhs-3.0.pdf.gz
/usr/share/doc/debian-policy/fhs/fhs-3.0.txt.gz
[...]

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

[Thorsten Glaser]

On Sun, 13 Jan 2019, Pierre Ynard wrote:

> You've moved them to /usr/libexec/ that doesn't exist on Debian, not
> /lib/init/ ?...

/usr/libexec/ is now allowed on Debian, but anything under /usr
does not seem to be the right place for things used by init,
unless these are late enough that /usr is always mounted when
they are used.

bye,
//mirabilos
-- 
tarent solutions GmbH
Rochusstraße 2-4, D-53123 Bonn • http://www.tarent.de/
Tel: +49 228 54881-393 • Fax: +49 228 54881-235
HRB 5168 (AG Bonn) • USt-ID (VAT): DE122264941
Geschäftsführer: Dr. Stefan Barth, Kai Ebenrett, Boris Esser, Alexander Steeg

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

[Pierre Ynard]

Hello, and thanks a lot for your work on the sysvinit package!

>* Move /etc/init.d/{rc,rcS} scripts out of /etc, retaining
>  symbolic link for compatibility (Closes: #132542)

https://salsa.debian.org/debian/sysvinit/commit/0766e7195229ee5563bc4ff3b6bf0a4b350c780d

> +debian/src/sysv-rc/rc  /usr/libexec/sysvinit
> +debian/src/sysv-rc/rcS /usr/libexec/sysvinit

You've moved them to /usr/libexec/ that doesn't exist on Debian, not
/lib/init/ ?...

-- 
Pierre Ynard

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

[Dmitry Bogatov]

[2018-12-20 09:34] KatolaZ 
> On Wed, Dec 19, 2018 at 11:40:48PM +, Dmitry Bogatov wrote:
> > 
> > control: tags -1 +moreinfo
> > 
> > [2015-12-01 23:07] Petter Reinholdtsen 
> > > In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> > > conffiles.  They should be moved to /lib/init/ instead.
> > 
> > Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
> > into /lib/init and adding symbolic links?
> > 
> > Any objections to this approach?
> 
> Why shall we move it at all?

Because sysadmin usually assume, that edits of anything under /etc
will be preserved between upgrades. And /etc/init.d/{rc,rcS} violate
this expectation.

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

[KatolaZ]

On Wed, Dec 19, 2018 at 11:40:48PM +, Dmitry Bogatov wrote:
> 
> control: tags -1 +moreinfo
> 
> [2015-12-01 23:07] Petter Reinholdtsen 
> > In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> > conffiles.  They should be moved to /lib/init/ instead.
> 
> Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
> into /lib/init and adding symbolic links?
> 
> Any objections to this approach?

Why shall we move it at all?

My2Cents

KatolaZ

-- 
[ ~.,_  Enzo Nicosia aka KatolaZ - Devuan -- Freaknet Medialab  ]  
[ "+.  katolaz [at] freaknet.org --- katolaz [at] yahoo.it  ]
[   @)   http://kalos.mine.nu ---  Devuan GNU + Linux User  ]
[ @@)  http://maths.qmul.ac.uk/~vnicosia --  GPG: 0B5F062F  ] 
[ (@@@)  Twitter: @KatolaZ - skype: katolaz -- github: KatolaZ  ]


signature.asc
Description: PGP signature

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

[Roger Leigh]

On 19/12/2018 23:40, Dmitry Bogatov wrote:


control: tags -1 +moreinfo

[2015-12-01 23:07] Petter Reinholdtsen 

In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
conffiles.  They should be moved to /lib/init/ instead.


Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
into /lib/init and adding symbolic links?

Any objections to this approach?


Not from me.  They aren't conffiles, and /lib/init is as good a place as 
any, unless you wanted to put them into /bin.  Ideally they would be 
best placed in /libexec, but this is banned in Debian for some dubious 
historical reasons.



Regards,
Roger

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

[Petter Reinholdtsen]

[Dmitry Bogatov]
> Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
> into /lib/init and adding symbolic links?
>
> Any objections to this approach?

No objections here.

--
Happy hacking
Petter Reinholdtsen

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

[Dmitry Bogatov]

control: tags -1 +moreinfo

[2015-12-01 23:07] Petter Reinholdtsen 
> In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
> conffiles.  They should be moved to /lib/init/ instead.

Dear co-maintainers, what about actually moving /etc/init.d/{rc,rcS}
into /lib/init and adding symbolic links?

Any objections to this approach?

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

[Petter Reinholdtsen]

In my view, /etc/init.d/rc and /etc/init.d/rcS should not be
conffiles.  They should be moved to /lib/init/ instead.

-- 
Happy hacking
Petter Reinholdtsen

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

[Benjamin Moody]

This bug was never fixed, as far as I can tell.  In version
2.88dsf-25, the file '/etc/default/rcS' (which is part of initscripts)
was made into a conffile.  However, '/etc/init.d/rcS' (which is part
of sysv-rc) never was.

The points raised in the original bug report remain valid today.
/etc/init.d/rcS is useful as a way to customize the early boot
sequence - for example, I have been using it to set the global CPU
affinity.  (Which I could have done by editing /etc/default/rcS
instead, but that's less obvious and arguably less flexible.)

Since /etc/init.d/rcS is human-readable and located in /etc, it is
reasonable for an administrator to expect that they can edit it and
have their changes preserved when upgrading the package.  Moreover,
the script is trivial - there's no reason for the file even to exist
if administrators aren't meant to be able to customize it.