Re: [users] Re: Time to fight for our beloved DEB format!
On Fri, Jul 06, 2001 at 05:49:10PM +0100, Eric E Moore wrote:
> Dave> Worse, though, is the case of a binary-only package which makes
> Dave> assumptions about running services based on runlevel. When it
> Dave> breaks because of customized runlevels, the admin _can't_ fix it
> Dave> except by going back to the LSB-defined scheme.
>
> Certainly, this is bad, however I imagine that altering the LSB
> specification to forbid this sort of idiotic behavior,
Idiotic? Perhaps. But I've seen its like many times in the years I
spent as a developer. Not only could I name programmers who would
take the easy way out, even if they knew they would have to go back
and fix it later (in hopes of being able to evade the fix by whining
about how it's too much trouble for too little benefit), I could also
name managers who would order their underlings to do it the wrong way
for the illusion of expediency. That sort of thing is plenty common
in the world of commercial software.
In any case, even if making assumptions based on current runlevel is
explictly forbidden by the standard, it will be done unless that
specific point is regularly tested for compliance by the certifying
body. Unfortunately, I would expect it to be a low priority for
testing, as it would only cause trouble on "non-compliant" systems.
> and saying that
> the runlevels are defined for the sole purpose of determining which
> runlevels to insert boot scripts into, and that relying on checking
> the runlevel is an error, would be well-recieved, whereas just
> chucking the whole thing, will not.
<cynicism>
Of course it wouldn't be well-received to suggest that the standard
be changed to make admins' lives easier at the cost of making things
a little more difficult for commercial developers. Which of those
two groups is writing the standard?
</cynicism>
> I disagree. Starting X may involve starting multiple services, xdm,
> xfs, it's certainly possible you don't want sound daemons running,
> unless you've switched into "workstation mode".
On the flip side, you may have a server (I know that I've got one)
which doesn't run X itself, but still wants xdm, xfs, etc. running
so that other machines on the network can attach to them. If you
can't know that a priori, why should the standard make assumptions
about it?
> Certainly, grouping
> together networking services (potentially a great many services) into
> a runlevel makes sense. Certainly, a network daemon should not be
> installed into a runlevel which doesn't ifup any interfaces.
Yes, but, unlike xdm, this is an easy one to test for. Just look at
ifconfig to see if any non-loopback interfaces are configured or
route to see if any routes are defined. Or, again, don't make any
assumptions - a standalone machine may want apache running so that,
e.g., dwww can make man pages available through netscape even if
there aren't any other machines to talk to.
> Certainly, an LSB 2 with an entirely new
> system for handling init, that has full dependency and pseudo-package
> (gdm/xdm/etc) support would be an exciting thing.
Indeed it would, but it dependency on a specific configuration of
runlevels can be removed without requiring the full dependency
information. The init scripts should have a pretty good idea of what
they need to work and can look to see whether those things are
running and exit if they aren't, just like the standard Debian init
scripts verify that the daemon's binary exists before trying to
execute it. Yes, if I decide to create a new zdm, I may have to
modify a script to tell it that zdm is an acceptable substitute for
xdm, but, IMO, that's a small price to pay for the assurance that, if
I rearrange my runlevels, (or, the next day, I write a replacement
for init that either doesn't use runlevels or allows an infinite
number of them) I won't have to worry about software malfunctioning
or not installing properly because I'm in violation of LSB's
assumptions about how I use my machine.
> Dave> `/etc/init.d/xdm stop|start` might
> Dave> call for a little more typing than `init 3|5`, but it's hardly
> Dave> difficult. And, to me at least, `xdm stop` obviously means
> Dave> "shut xdm down", while `init 3` has no readily apparent
> Dave> relationship to X or xdm unless you're bringing outside
> Dave> knowledge with you.
>
> Agreed. Assuming, of course, you don't run xfs or rplay, or anything
> else you want running with X. In which case it does make sense to
> group those things together. The only mechanism we have now in init,
> is runlevels.
You make a good point. Perhaps the better avenue, then, would be to
work up a standard for defining groups of services which can be
started up and shut down together, rather than trying to standardize
on a 'one size fits all' set of runlevels. It might even be easier,
although I can already see a few problems that would have to be dealt
with.
Just to throw in a little history here (and risk incurring the wrath
of the Open/Free Software equivalent of Godwin's Law), the first
thing I learned when I encountered Microsoft Access was that it made
writing certain types of applications incredibly easy. The second
thing it taught me was that, to achieve that ease, it made a lot of
assumptions about what the user wanted to do and those assumptions
made it very difficult (sometimes bordering on impossible) to get it
to do anything else. Since then, I've learned that it is only very
rarely that you can make specifically foreseen tasks easier without
making unforeseen tasks more difficult as a side effect.
I believe that any attempt to assign standardized meanings to
runlevels falls into this category: It makes it easier to setup a
system that does normal things in a normal configuration and easier
for third parties to set up software for installation on these normal
systems. But not all systems are normal and I don't think that any
standard should be written which makes those systems non-compliant by
default. Thus I maintain that Debian has the right idea: The distro
makes no assumptions about how you use your runlevels. If you want
them all to be identical, that's fine. If you want to configure them
so that networking is only enabled in runlevel 8 (yes, according to
man init, "Runlevels 7-9 are also valid, though not really
documented") and network services are only started in runlevel 1, go
right ahead; Debian doesn't care. (Well, OK, Debian does make one
assumption: Newly-installed services are installed in all runlevels,
which is equivalent to assuming that, if you install something, you
want to have it running. Seems reasonable to me, particularly given
that the alternative minimal assumption is to not run it by default.)
Reply to: