Re: rc?.d policy?
*- On 10 Aug, Noah L. Meyerhans wrote about "Re: rc?.d policy?"
> -----BEGIN PGP SIGNED MESSAGE-----
>
> On Tue, 10 Aug 1999, Brian Servis wrote:
>
>> But if a user removes the S99xdm link in rc2.d then the next time xdm is
>> upgraded it will be added again. This issue of the package managment
>> tools over writing what the system administrator sets has been debated
>> before, in favor of the system administrator(Recall the /usr/doc/*.gz
>> issue recently on -devel). This is what I was describing. Mike, or
>> anyone else, can you clarify why Debian does not have a destinction
>> between user runlevels for things like networking, X, etc?
>>
>
> I do not believe that is the case. The upgrade of xdm will run
> update-rc.d, which will see that there are already symlinks installed and
> exit without changing anything. That is, unless the -f option is passed
> to update-rc.d, which should probably not be the case in any package.
>
> This assumes that there is at least one symlink for this package somewhere
> in rc*.d. If there are no symlinks at all (why upgrade the package if you
> don't use it?) then update-rc.d will create them.
>
> I could be wrong, but this seems to be my experience.
> noah
Ok, perhaps I have misunderstood the man page section:
If any files /etc/rcrunlevel.d/[SK]??name already exist
then update-rc.d does nothing. This is so that the system
administrator can rearrange the links, provided that they
leave at least one link remaining, without having their
configuration overwritten.
I took this to mean that if a link existed for one particular runlevel
then it would not be modified, but if a link did not exist for that
runlevel and the update-rc.d command line was asking for it (without
-f) then it would be created.
I stand corrected. Sorry.
I still think Debian should have a default policy on runlevels for X,
networking, etc.
--
Brian
---------------------------------------------------------------------
Mechanical Engineering servis@purdue.edu
Purdue University http://www.ecn.purdue.edu/~servis
---------------------------------------------------------------------
Reply to: