Hi Jaromil, list, Jaromil writes:
> dear Olaf, > > On Mon, 20 Nov 2017, Olaf Meeuwissen wrote: > >> Crying wolf like this time and again is not doing Devuan any good. > > No, I am the wolf. I do not mean this personally. I just recalled the mail that set off the redis discussion and this one and noticed one thing in common: a lack of backing up claims without proper investigation. If anyone wants to make a claim about anyone else "sabotaging" non-systemd systems, just show some cold, hard facts to back it up before pointing fingers one way or another. # FTR, I've been using Debian since 1998 and switched all my machines to # Devuan in 2017 because, eh, I think systemd is getting in *my* way. >> FWIW, I just modified the /etc/rc.local on two of my Devuan ASCII >> machines to fix up ownership on an ext4 mount and that worked just >> fine. But then again, initscripts *is* devuanized ;-) >> >> Hope this helps, > > It doesn't: you are bringing confusion. Actually, with respect to the quoted paragraph, you're probably right. I should have left that out. It detracts from the rest of what I wrote. > You have checked Devuan. I'm talking about Debian 9 "Stretch" In the same mail you replied to, I also wrote: >> Just a simple `grep -rl rc.local /var/lib/dpkg/info` is all that it took >> me to find this out on my Devuan Jessie. To cross check, I went over to >> package.debian.org to have a look at their initscripts package. stretch >> has 2.88dsf-59.9, buster and sid have 2.88dsf-50.10. Pulled the debian/ >> directory tarball and checked initscripts.postinst. Nothing changed and >> rc.local will still be created. So, yes, I *did* check Stretch and Buster and Sid. To make really sure, I just eyeballed the initscripts.postinst files again and they *create* an /etc/rc.local file 'on first install and when upgrading from versions before "2.86.ds1-16"'. To make absolutely really sure, I checked the Debian Docker images for Stretch and Buster. Neither has an initscripts package installed and /etc/rc.local is missing. I installed initscripts on both and in both cases an /etc/rc.local file was created. # FTR, both the Debian Stretch and Buster Docker images come *without* # systemd installed. This is due to the nature of containers as they # are supposed to run just a task-specific, dedicated program as their # PID1. For the Debian containers that is /bin/bash, BTW. > Here the rumors I've heard from bitcoin core development: a CI script > was broken for three reasons, of which the mandatory activation of > rc.local via systemctl is just one. > https://github.com/bitcoin-core/docs/blob/master/gitian-building/gitian-building-setup-gitian-debian.md > > also "rumors" of "deprecation" are all around the web with a search: > https://stackoverflow.com/questions/44797694/where-is-rc-local-in-debian-9-debian-stretch > http://www.itechlounge.net/2017/10/linux-how-to-add-rc-local-in-debian-9/ I cannot say I have really *read* these but I have at least skimmed them and the problem seems to be that they assume /etc/rc.local is provided by some package that is installed by default. Until Jessie, initscripts was Priority: required so it was installed by default. As of Stretch, it has become Priority: optional and will not be installed by default. A quick check of the packages that would pull it in (as per massaged `apt-cache rdepends`) on Stretch gives: $ apt-cache rdepends initscripts | sed -n '/^ /p' | while read pkg; do \ echo $pkg ; apt-cache depends $pkg | grep initscripts; done \ | sed -n '/^[^ ]/{ H; N; /Depends/P }' sysvinit-core debian-edu-config console-setup-linux console-setup-freebsd console-log but note that there are a fair number of packages that declare a Breaks: or Conflicts: which may warrant further investigation. As for Devuan, it flags sysvinit-core as Priority: important and therefore the initscripts package will be pulled in. > there is no official mention on Debian about a "deprecation", which > I'd consider vandalism. I am very happy of that and I'm asking if its > real or not that is "deprecated" as others write and if anyone knows > more about Debian's long term intention with rc.local, since its > function has already changed: > > 1- it is not created by default Please note the that the /etc/rc.local that is created by default is no more than #!/bin/sh -e exit 0 once you remove the documentation. Anyone that knows about and needs an rc.local can whip up something more meaningful in, what?, 10 seconds. > 2- it is not executed in Debian Stretch (9) even if existing Now, here is something I am not sure about but the content of the pages in your last two links seem to suggests that it is *systemd* that no longer honours a /etc/rc.local by default and requires you to explicitly enable it. If that's the case, I would not call that Debian vandalism but systemd vandalism and every distribution that defaults to systemd will be affected alike, not just Debian. Debian has chosen systemd as it blessed default (something I don't agree with but that's besides the point), so, yes, the initscripts package is no longer Priority: required (considering its content). If systemd then decides that it can't be bothered or cope with "legacy" stuff such as /etc/rc.local (I'm assuming here that this behaviour is *not* courtesy of a Debian specific patch without actually checking, ignoring my own advice!), then that's what the Debian default deservedly gets. > please correct me if I'm wrong. That would help. Looking over all of the above, I'd say that you're wrong claiming that rc.local has been *removed* from Debian 9. Just install initscripts and it's there. If you had claimed that systemd is ignoring /etc/rc.local by default, you might just be right but I'll leave that for you to back up :-) Hope this helps, -- Olaf Meeuwissen, LPIC-2 FSF Associate Member since 2004-01-27 GnuPG key: F84A2DD9/B3C0 2F47 EA19 64F4 9F13 F43E B8A4 A88A F84A 2DD9 Support Free Software https://my.fsf.org/donate Join the Free Software Foundation https://my.fsf.org/join _______________________________________________ Dng mailing list Dng@lists.dyne.org https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/dng
