Hi On 2016-01-15, Alec Leamas wrote: > On 15/01/16 19:04, Russ Allbery wrote: > > > > I feel like removing the sysvinit scripts entirely would be "reverting > > existing support without a compelling reason." But I also think that > > people who want to use sysvinit (or upstart, or any other init system) > > will have to contribute some support there in the form of bug reports and > > patches, just as with any other non-default configuration in Debian. Your > > obligation as maintainer is to "merge reasonable contributions" as > > mentioned above. > > OK, seems that all agree that the scripts should be kept in the package. > So the question then becomes how. As you might have understood I have a > bad gut feeling about them. > > Given this, would it be OK to put the sysV scripts in a separate > subpackage which can be properly commented?
As Michael Biebl already mentioned, this is overkill (and borderline broken, because the hypothetical 'lirc-sysv' won't be pulled in by upgrades, thereby breaking kfreebsd-any and hurd). Working sysv initscripts for lircd/ lircmd/ irexec: http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircd.init?view=markup http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.lircmd.init?view=markup http://anonscm.debian.org/viewvc/pkg-lirc/lirc/trunk/debian/lirc.irexec.init?view=markup which are masked by the according, upstream provided, systemd units, therefore being a no-op on systems using systemd and drop-in replacements for systems not using it (respectively not being able to use systemd yet, namely kfreebsd-amd64, kfreebsd-i386 and hurd). The maintenance overhead for these is minimal, at least for the time being, unless there are significant (upstream) changes in the queue for lirc and there is little excuse to intentionally break support for sysvinit (== non-linux ports). Combined, these three initscripts (including lots of whitespace) are 5 KB in size, the packaging overhead (/usr/share/doc/<PACKAGE>/ and the space this required in the package indices, e.g. Packages.gz) for these would far bigger than the potential gain of stripping them out (the only advantage would be being able to drop the dependency on lsb-base, a whopping 51 KB installed package size --> not worth it, even assuming lsb-base wouldn't be required by many other core packages anyways). Regards Stefan Lippers-Hollmann
pgpPJNl3LgbCu.pgp
Description: Digitale Signatur von OpenPGP
