Stories
Slash Boxes
Comments

SoylentNews is people

posted by janrinok on Wednesday November 19 2014, @11:25AM   Printer-friendly
from the I-hope-we-don't-regret-this dept.

Ian Jackson's general resolution to prevent init system coupling has failed to pass, the majority vote deciding that the resolution is unnecessary. This means that not only will Debian's default init be systemd, but packages will not be required to support other init systems. Presumably, this means that using other init systems on Debian (without using systemd as a base) will not be possible without major workarounds, or possibly at all. It also leaves the future of Debian projects such as kFreeBSD unclear, as systemd is linux specific.

The vote results can be found here

The winners are:

Option 4 "General Resolution is not required"

 
This discussion has been archived. No new comments can be posted.
Display Options Threshold/Breakthrough Mark All as Read Mark All as Unread
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
  • (Score: 2) by tibman on Wednesday November 19 2014, @08:39PM

    by tibman (134) Subscriber Badge on Wednesday November 19 2014, @08:39PM (#117839)

    A daemon/service should not require init source code in order to build itself. Init should not require the daemon source in order to build. They should both be capable of building without knowing about each other. An optional intermediary that understands the daemon and the init can be used by the init system to start the daemon. That intermediary is usually a configuration file and/or script that the init understands. It depends on both the init system and the daemon. This allows you to use the same service with various init systems. The only thing required to make the service function with a new init is a new intermediary. The developers of the daemon/service don't even have to know about the new init system. They don't care about init systems, they care about their service. Usually a distro package manager would care about such things.

    An alternative is the service developer using defines that can be toggled on and off at build time. So it becomes possible for a service to optionally depend on a specific init/library. This allows for the developer to directly support functioning with a foreign project but still allow the service to function if that foreign project dies, is forked, or becomes deprecated.

    If you tie yourself to a foreign project then you tie yourself to its fate. If you want your software to continue functioning no mater what happens with the rapidly fluctuating open source ecology then you need to minimize hard dependencies.

    --
    SN won't survive on lurkers alone. Write comments.
    Starting Score:    1  point
    Karma-Bonus Modifier   +1  

    Total Score:   2