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

Re: REISSUED CfV: General Resolution: Init system coupling



Hi,

On 09.11.2014 15:08, Lucas Nussbaum wrote:
> We have had scenarios in Debian where maintainers, tired of receiving
> bug reports about problems on a specific architecture, decided to drop
> support for that architecture from their packages.

True. Yet we didn't forbid them by GR to do so because that's a vast
minority. Why would the init system need a special regulation here?

> Not really. Some init systems (at least systemd and upstart) provide
> advanced features that are not available in any other init systems.  If
> this proposal passes, I think that it would be fairly reasonable for
> upstreams or maintainers to start making more advanced uses of systemd
> service files, and at the same time, remove init scripts when it's not
> possible to alter them to match systemd service files functionality.
[..]
I think that it's important to not just think
> about the current state of things, but also look further about what it
> would mean in the more distant future.

In a more distant future, upstart will be dead and forgotten, as
upstream abandoned support for it.

At that point it's about discussing whether to use systemd service files
or not and I have a hard time to come up with a scenario that couldn't
be worked around to a large extent using traditional init scripts, or
whatever magic openrc provides, if somebody is willing to take that work.

Daemon's service files aren't our problem, really. The problem arises by
upstreams that are requiring some other tightly related features
provided by systemd exclusively. If upstream decides to go that road I
think it's not up to us to cripple their software and provide our users
software in a way it was intended to use instead. If that means to
exclude a certain fraction of Debian users, that's bad but not our
decision. Luckily Debian is "universal" enough to provide other software
in our repositories which may fit into the same sport, and may not have
such constraints.


-- 
with kind regards,
Arno Töll
IRC: daemonkeeper on Freenode/OFTC
GnuPG Key-ID: 0x9D80F36D

Attachment: signature.asc
Description: OpenPGP digital signature


Reply to: