Bug#834524: init-system-helpers: does not own /etc/rc?.d

[Felipe Sateler]

On 19 August 2016 at 15:24, Josh Triplett <josh at joshtriplett.org> wrote:
> On Wed, 17 Aug 2016 12:34:59 -0300 Felipe Sateler <fsateler at debian.org> wrote:
>> On 17 August 2016 at 03:45, Ferenc Wágner <wferi at niif.hu> wrote:
>> > Michael Biebl <biebl at debian.org> writes:
>> >
>> >> Am 16.08.2016 um 19:12 schrieb Ferenc Wágner:
>> >>
>> >>> Recently both my daemon packages started to exhibit this piuparts error:
>> >>>
>> >>> ERROR: FAIL: Package purging left files on system:
>> >>>   /etc/rc2.d/         not owned
>> >>>   /etc/rc3.d/         not owned
>> >>>   /etc/rc4.d/         not owned
>> >>>   /etc/rc5.d/         not owned
>> >>>
>> >>> I think this is the result of sysv-rc losing its Essential flag, which means
>> >>> it isn't present in minimal chroots (like those used by piuparts) anymore.
>> >>> On the other hand, init-system-helpers imported update-rc.d in version 1.25,
>> >>> and I think /etc/rc?.d is created by update-rc.d (but never removed).  All
>> >>> this results in piuparts failures in recently tested daemon packages.
>> >>>
>> >>> If the above analysis is correct, please fix this.
>> >>
>> >> Fix what exactly?
>> >
>> > The piuparts errors.  By taking ownership of the /etc/rc?.d symlink
>> > directories.  (Removing them if they become empty is another option, but
>> > does not sound a very good idea.)  Previously they were owned by
>> > sysv-rc, which also provided update-rc.d, which used these directories.
>> > When update-rc.d moved into init-system-helpers, /etc/rc?.d should've
>> > followed along, but was forgotten, I guess.
>>
>> Indeed. init-system-helpers even already did this for
>> /etc/systemd/system. I have added the rc?.d directories to the list.
>>
>> https://anonscm.debian.org/cgit/collab-maint/init-system-helpers.git/commit/?id=62e093e7949a25479cbc78d01903f76f49629059
>
> This will cause the directories to continue to exist even when empty.

Yes.

>
> Ideally, these directories could become empty and disappear eventually,
> on a system not running sysvinit.  What would it take for that to
> happen?

A lot more than reverting that commit :)

On my system I see:

% dpkg -S /etc/init.d/*
avahi-daemon: /etc/init.d/avahi-daemon
binfmt-support: /etc/init.d/binfmt-support
cron: /etc/init.d/cron
dbus: /etc/init.d/dbus
util-linux: /etc/init.d/hwclock.sh
procps: /etc/init.d/procps
rsync: /etc/init.d/rsync
openssh-server: /etc/init.d/ssh
sudo: /etc/init.d/sudo
udev: /etc/init.d/udev
unattended-upgrades: /etc/init.d/unattended-upgrades
x11-common: /etc/init.d/x11-common

util-linux is essential, udev is pretty much required on
non-containers. Procps and cron are Priority important.

As long as we support non-systemd init, all of those need to ship init
scripts. And as long as they do, there will be /etc/rc?.d directories.

-- 

Saludos,
Felipe Sateler