Hi Michael, On Tue, Jan 28, 2020 at 04:38:36PM +0100, Michael Biebl wrote: > Hi Andreas, > > thanks for your interest in this topic.
Thanks for your interest in my interest. :) Always nice with some feedback. > > Aside from /bin/pidof, we also have ... a bunch of niche tools that has been discussed before. I haven't really looked at these recently but I guess not much has changed, except maybe init-d-script has gotten a bit wider usage. Will try to give some kind of updated status for these below... > > /sbin/fstab-decode Still only 2 users found by codesearch: drbl, open-iscsi > /sbin/killall5 Still very few users. The following codesearch hits seemed somewhat relevant to investigate: util-vserver, apcupsd, lxc-templates (likely not shipped), drbl, rear > > I haven't checked codesearch if those binaries are used outside of > sysvinit/initscripts. Have you investigated those recently? > > > And there is also > /lib/init/init-d-script In the past this had few users. These days I'd say the better fix than adding sysvinit-utils dependency is to just require users of init-d-script to also ship a masking native systemd unit. There are 73 total hits for init-d-script on codesearch (including false positives like lintian), so certainly still manageable. > /lib/init/vars.sh >From random samples this seems exctusively used from init scripts (and examples of init scripts), so I'd say a masking native systemd unit would be my preferable fix (rather than a sysvinit-utils dependency). There are 280 codesearch hits. > > Those are the more tricky ones. A lot of init scripts use them. > Not having those installed will render the init scripts of packages > broken. It's less of an issue, if a package ships a native service file. > (Do we know for how many this is the case, i.e. no .service file, SysV > init script using init-d-script and/or vars.sh?) (I just have to start by saying, dropping 'Essential: yes' doesn't mean people will stop having sysvinit-utils installed. The literal definition of 'Priority: required' is that your system will break if you remove this package. I guess you're thinking ahead of potential future lowering the priority....) I haven't investigated how many of the init-d-script and vars.sh issues are already solved. I'll however volunteer to look all of the affected packages over (and hopefully submit patches for them) once the 'Essential: yes' bit is dropped. (I'll *not* look them over before 'Essential: yes' is dropped, simply because that's alot of work that will rot and will have to be redone again and again and again. So just a waste of my time.) > Also, we have /etc/init.d/foo → redirection to systemctl broken unless > /lib/lsb/init-functions is the first thing that is sourced. > Maybe that breakage is acceptable? Dunno. > What are your thoughts here? I think at as time goes by assuming people being used to init scripts rather than systemctl/service commands becomes less and less true. I might be to progressive but I'd say we're now at a point where it's not very important to keep shielding the users from mistakes like directly invoking an init script. While many oldtimers could likely spell out the full /etc/init.d/foo path of a number of important services in their sleep, I also think there's a whole generation of people around now that administer systems without knowing what /etc/init.d does at all. > > Given the size of the sysvinit-utils package, last time I looked into > this I concluded it's probably not worth the trouble. But maybe things > have changed by now. I agree with this, but the reason I'm here again is because I've managed to tick off most of the issues which had higher payoff already. It's this one and #833256 (where I'd make the new packages non-essential in the same go) left from my old investigations.... then there are the "legendary" ideas that is as insane/unrealistic amount of work like getting bash or perl out of the base. (But the value is not very high there either, so I'd say it's even less worth to work on that than this.) Then there's things that might really painful (if at all possible) but more rewarding, like shrinking the largest packages in the base system: e.g. coreutils. While size is one factor, I think getting rid of essential where not needed has value in that dependencies can actually be properly declared/tracked. For all the normal reasons in debian why being able to track the dependencies is good, there's also likely value in bootstrapping as well as more easily being able to build custom minimal systems. Regards, Andreas Henriksson
