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

Re: enable/disable flags in /etc/default



        Hi!

 As someone who is also annoyed by the default file startup hack (which
is IMHO an abuse because why have a S rc link then?), let me also throw
in my 0.02 EUR.

> Stig Sandbeck Mathisen <ssm@debian.org> writes:
> > The "short term" issue is figuring out if the current practice of
> > DONT_DISABLE_ENABLEMENT=false and friends in /etc/default is something
> > we want to keep doing.

 Actually I explicitly chose to not go down that path for
wesnoth-server. I settled for this approach:

dh_installinit -u 'stop 20 0 1 2 3 4 5 6 .'

 This sets the symlinks for the service to be disabled by default and
leaves it to the administrator to switch to S symlinks. Actually now
that I look at it I think I might have triggered a bug in update-rc.d
here, why does that only create K links in rc{0,1,6}.d but *not* in
rc{2,3,4,5}.d?

 Also, the update-rc.d foo enable hack seems to not work in this case,
it seems to depend heavily on the LSB information (and thus ignoring an
administrator's choise for settling for different runlevels).

 And being able to support the local admin is why I have to chose to set
the rc links to kill links by default: If they want to tweak their
runlevels they have to tweak the symlinks. If they have to touch an
*additional* default file they would get annoyed (actually, _I_ get
annoyed by that, having to tune the rc symlinks *and* the default file
to do it properly).

* Russ Allbery <rra@debian.org> [2011-03-02 00:20:52 CET]:
> > The "long term" issue is having a toolset, for the end user, for
> > starting and stopping services, enabling and disabling services when
> > booting, installing and upgrading, and setting a global policy for what
> > the initial status of an installed service should be.
> 
> Speaking as someone who has a few of the DONT_NOT_DISABLE_SERVICE
> variables in some of my packages, I think you have the order reversed
> here.  I agree that those settings are horrible, but as horrible as they
> are, they're less weird than our current user interface for disabling init
> scripts.

 From a point of view that all runlevels are the same I would agree with
you. But actually there are different runlevels for a reason, and
personally I really would like to see Debian actually move forward on
that grounds, offering more useful runlevels which actually are
different by default like suggested in the LSB instead of having them
all do the same.

>  (Users have at least a hope of finding it, which is not really
> true in my experience of the init method at present.)  I'm therefore not
> inclined to remove them until we provide a non-horrible user interface
> that can really replace them.

 file-rc actually has a saner user interface in that respect from what I
understood.

> > What I'd like to be able to do, is to set a policy after system install,
> > and have all packages _obey_ this policy. :)
> 
> Yup, I think that's the right order.  :)

 Well, I personally don't like to treat _all_ packages the same, and I
don't think that this is just me?

 So long!
Rhonda
-- 
"What are the differences between Mark Zuckerberg and me? I give private
 information on corporations to you for free, and I'm a villain.
 Zuckerberg gives your private information to corporations for money and
 he's Man of the Year."         -- Julian Assange


Reply to: