[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Pre-Depends: init-system-helpers

On Mon, 17 Nov 2014, Anthony Towns wrote:
> If deb-systemd-* were to get merged in, it might be worth doing a name
> change at the same time, I guess. Changing either before jessie doesn't
> seem remotely plausible.
> I wonder if it would make sense to just merge it all into the "service"
> command; ie:
>    # service --use-policy ssh start
>    # service --use-policy ssh restart
>    # service ssh enable
>    # service acpid.socket mask-for-upgrade

"service" is an user interface, while deb-systemd-*, invoke-rc.d, and
update-rc.d are first and foremost to be used by a package's maintainer
scripts (postinst, etc).  They have different design goals.

IMHO it is best that we keep system interfaces separate from user interfaces
like "service", although I certainly have nothing against extending
"service" with more user functionality.  Just have "service" call into the
system interfaces when required if you extend it.

> in place of:
>    # invoke-rc.d ssh start
>    # invoke-rc.d ssh restart
>    # update-rc.d ssh enable
>    # deb-systemd-helper mask acpid.socket
> I wonder a bit if it wouldn't make even more sense to just make the common
> command be "systemctl", with Debian-specific patches for --use-policy

I'd advise against that.  We really should have Debian be the upstream of
the interface layer used by maintainer scripts of deb packages.

This is also part of the reason I don't like the idea of folding this stuff
into "service".  "service" is somewhat compatible across distros, you don't
mess with that lightly.

> and the various extra behaviours where necessary. Maybe just having a
> "systemctl" script with mostly compatible syntax provided for alternative
> inits would be a better approach. (The disadvantage to that would be
> that systemctl's a C program, so patching Debian specific options would
> be harder than with sh/perl scripts like service/deb-systemd-*/*-rc.d)

Let's just avoid this whole can of worms, please.

I have no strong feelings about these utilities being implemented in perl,
shell or C, as long as they don't make a mess of the base system or become
fragile during a worst-case dpkg breakage party.

  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh

Reply to: