[Initscripts-ng-devel] Defining the workgroup objectives
Henrique de Moraes Holschuh
hmh at debian.org
Wed Jul 27 10:56:34 UTC 2005
On Mon, 25 Jul 2005, Jay Berkenbilt wrote:
> * Is it worth including something about the appearance of the booting
> system in the list of objectives? I think having a standard
Yes, as the interface should somehow allow the initscript subsystem to
intercept all non-syslog output, and to actually know exactly WHAT the
initscript is attempting to do (will try to start, started ok, failed to
How that information will be conveyed to the user is not for the objectives
to list, however.
I will add it.
> * Support for interactive startup (as is available in Fedora).
> Supporting this is low-impact as it doesn't really impact
> individual init scripts, but if the interface supports it in a
> well-defined way, init scripts that may start more than one service
> could hook into it to allow the individual services to be
> controlled separately. Interactive startup is great for situations
> in which a system's startup process is being debugged, to
> temporarily work around network outages, or during system
Good point. But this gets rather tricky to do with any sort of dynamic
dependency in place, since all you can do is to ask if a service should be
started or not in an unspecified order, and THEN attempt to run the whole
Anyway, to me it doesn't look like a characteristic we must enforce on *all*
initscript systems, just something good to have in whichever one we ship for
desktops by default, for example. So IMHO it doesn't belong in the
> * Is it out of scope to define or suggest policy about what should
> and should not happen in single user mode? I've personally always
Yes, for the objectives, at least. Probably for everything else as well :)
This is a per-distribution policy thing IMHO.
Not that we cannot discuss this within Debian and define it better [for
Debian], but the correct place to do that would be the debian-devel
mailinglist, and later the debian-policy mailinglist. And it doesn't have
to wait for what we're doing here, either. It is orthogonal to our
workgroup's goals, IMHO.
> Since it will be very hard to get consensus on this, another
> possible way to handle this might be to specify an interface that
> supports administrators tweaking some of this stuff and having
> those tweaks survive across upgrades in much the same way disabling
> service survives across upgrades in Debian currently.
That one is a given. I will add it, although I thought it was pretty much
Both the local admin (whose interface we will not be poking at, other than
whatever we want done in our 'perfect dep-based initscript system') and the
packaging system (whose interface we WILL be defining strictly) must be able
to manipulate how things will happen.
> * Debian lacks a "nice" way to control what does and doesn't start.
It doesn't. That's what policy-rc.d does. Writing a frontend to that can
be a separate (Debian-centric) goal, but I don't see why the interfaces and
other high-level stuff should even bother with it [apart from our 'perfect
dep-based initscript system' design phase, which will come later].
> Having a program like update-rc.d (or, as you suggest,
> register-rc.d) is great for maintainer scripts, but it's not really
> intended to be used by end users. I like the fact that update-rc.d
I will add producing a few UIs to the objectives list. What kind of UIs
does not belong in that document.
> Even if these items end up showing up again later on when actual
> requirements for the system are constructed (after more fundamental
> decisions are made), I think these are some points worth remembering
> as they will be important to many users, particularly those who don't
> necessarily have a deep understanding of the boot process.
"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
More information about the initscripts-ng-devel