Hello Craig Small. Thanks for taking this on and drafting a proposal... I'll throw in some of my own ideas below in case they're helpful so feel free to leave out or reword things as you see fit.
Fwiw, in case you want to avoid any potential people out there who might think you're just beating a dead horse for your own personal gain feel free to start out with "I've been asked to..." which should hopefully kill off those ideas from the get-go. On Thu, Jan 07, 2016 at 09:17:41AM +1100, Craig Small wrote: [...] > So, to the actual proposal. I need help especially around the why. > > =================== > What: > Create a new package procps-base. This uses the existing procps source > package and just enable building of pidof. procps-base will be an > Essential package and only contain pidof. Short and clear. +1 > > Why: I see what you wrote mainly as a long-term why.... I'd like to add a short-term: Make sure more of the essential utilities in the base of the operating system comes from active and healthy upstreams. Also in general I think it's good to make sure we don't /needlessly/ deviate. This means we can benefit from issues discovered in other distributions and fixed upstream, while at the same time we can be good free software citizens and bring our own fixes upstream for the benefit of the entire free software echosystem. Hopefully pidof is trivial enough that it won't need much fixes though. > The aim is to make the sysvinit-utils package non-essential. This > was discussed previously in 2013 [1], however there are some important > differences between 2013 and now. > 1) The previous change was due to possible upstream relocations of > pidof. This is about Debian package contents. > 2) In 2013 there were a lot of other programs in sysvinit, in 2016 > we're down to 4 (pidof, service, fstab-decode, killall5) > > (why change from one essential to the other?) Why? See above. Otherwise I think this part is good as is. Some minor ideas: - maybe say "longer term plans/ideas..." since I'm not vouching we'll be able to actually pull off makintg sysvinit-utils non-essential before stretch release. - maybe tone down making sysvinit-utils non-essential since I think that should be a separate discussion (and more considerations than just pidof and service, etc, needs to be taken into consideration). Providing procps pidof is a useful idea on its own in my opinion. > > What about the other binaries in sysvinit-utils? > pidof - moves to new Essential package procps-base > service - moving to init-system-helpers [2] > fstab-decode - 2 packages use this (open-iscsi, drbl) > killall5 - 2 packages use this (openrc, util-vserver) > The idea would be those 4 packages would depend on sysvinit-utils. > pidof is used be far too many packages to have the same treatment. I've also spent some time on researching the pidof users and the main user seemed to be direct invokations from init scripts. These could benefit from being converted to LSB "pidofproc" helper function (which falls back on executing pidof if available though). I'm not sure the busy work of fixing all init scripts is worth it though. Personally I'd rather spend my time on writing native systemd unit files (which will probably be easier to reuse from other potential future init systems than LSB init scripts), and I doubt the vocal people who shys away from anything systemd related is willing to actually step up and help out with the practical work either. So not sure if it's worth even mentioning LSB pidofproc... maybe in a short paragraph somewhere. > > What other packages will procps-base depend on? > libc6 and libprocps5. libprocps would be newly pulled in. Would likely be good to mention what sysvinit-utils pulls in for comparison, eg. In comparison sysvinit-utils pulls in: libc6, libselinux1, startpar (Maybe skip mentioning libc6 in both cases.) > > > 1: https://lists.debian.org/debian-devel/2013/12/msg00121.html > 2: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=805487 > > =================== > - Craig HTH. Regards, Andreas Henriksson
