Qs about debian

Qs about debian

Post by Michael Pow » Thu, 30 Sep 1999 04:00:00



-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

1. Why is emacs 19.34 the default emacs when I installed debian with
   the `huge development' package?  emacs 19.34 is 3 years old.

2. Why do I get xdm for a login when I didn't ask for it?

3. Why is the default compiler (gcc) version 2.7.2.3?  It's more than
   2 years old.  Should I really believe that that is the version that
   debian maintainers are using?

4. In my /usr/bin, I have three copies of everything associated with
   emacs -- one copy for emacs 19, one for emacs 20, and one for
   xemacs.  That makes something like 20 files altogether.  Then, in
   /etc/alternatives, I have symlinks pointing to each of these items.
   Why?  It's a mess.

5. The /etc/rc[0123456].d/ dirs are filled with symlinks pointing to
   /etc/init.d/, instead of having actual boot scripts, like normal
   systems do.  Why?

Just a few questions that come to mind since I installed debian last
week, replacing my slack setup.  

mp

     ------------------------------------------------------------
        "Language is the dress of thought."  -- Samuel Johnson
- --

Portland, Oregon USA                       http://www.trollope.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: Mailcrypt 3.5.3/GnuPG v0.9.8 http://www.gnupg.org

iD8DBQE38cRu755rgEMD+T8RAipFAKCxZPRlhrARlLQg5qNzNeefiQwhlgCeI/VD
uqiA1bDa+rurLGBmXAJsorQ=
=fzDo
-----END PGP SIGNATURE-----

 
 
 

Qs about debian

Post by Stefano Ghirlan » Thu, 30 Sep 1999 04:00:00



Quote:>5. The /etc/rc[0123456].d/ dirs are filled with symlinks pointing to
>   /etc/init.d/, instead of having actual boot scripts, like normal
>   systems do.  Why?

I think this is the difference between so-called BSD-style init
(slackware) and SysV-style init. The first has fewwer files, it's easier
to understand what happens at boot. The other is more dofficult to
understand (for me at least) but you can actually stop/start deamons
individually.

--
 Stefano Ghirlanda, Zoologiska Institutionen, Stockholms Universitet
    Office: D554, Arrheniusv. 14, S-106 91 Stockholm, Sweden

   Support Free Science, look at: http://rerumnatura.zool.su.se

 
 
 

Qs about debian

Post by Mark Brow » Thu, 30 Sep 1999 04:00:00



> 1. Why is emacs 19.34 the default emacs when I installed debian with
>    the `huge development' package?  emacs 19.34 is 3 years old.

Emacs 19 still works perfectly well for a lot of uses - the main
tardis (see e-mail address) machine was running it as the default
Emacs until relatively recently without user complaints.  Emacs 19 is
also required for some Emacs Lisp programs.

I'm not entirely sure why it's the default Emacs, although I suspect
that the fact that the disk footprint is 10 megabytes smaller has a
lot to do with it - many users won't notice the feature differences
but will notice the disk space.  I could be wrong, though.

Quote:> 2. Why do I get xdm for a login when I didn't ask for it?

You installed the xdm package, which runs xdm by default.
Deinstalling the package or fiddling with the init script will stop it
running.

Quote:> 3. Why is the default compiler (gcc) version 2.7.2.3?  It's more than
>    2 years old.  Should I really believe that that is the version that
>    debian maintainers are using?

It's only the default gcc - the C++ and Fortran compilers are the EGCS
ones and is also an egcs package as well which installs the EGCS C
compiler as egcc.  Since version 2.0 kernel is only guarenteed to work
with gcc 2.7.2 and requires some unofficial patches for use with EGCS
gcc 2.7.2 is the version chosen to provide the gcc command.

Now that the kernel will build with EGCS and EGCS has become GCC this
problem has gone away and the development version of Debian uses one
current version of GCC for all the relevant compilers.

Quote:> 4. In my /usr/bin, I have three copies of everything associated with
>    emacs -- one copy for emacs 19, one for emacs 20, and one for
>    xemacs.  That makes something like 20 files altogether.  Then, in
>    /etc/alternatives, I have symlinks pointing to each of these items.
>    Why?  It's a mess.

Well, you did select the *huge* development package.  :-)

I guess the reason for installing them all is that while Emacs 19 is
standard developers are more likely to want the more current version
and taking sides in the Emacs/XEmacs debate would annoy some people.

The main reason for the symlinks in /etc/alternatives is that there
are multiple binaries for the Emacsen - XEmacs has xemacs20-mule,
xemacs20-nomule and xemacs20-mule-canna-wnn versions while both Emacs
19 and Emacs 20 are packaged.  Whichever you have installed (and it is
possible you'd want more than one of each) you want the right.  thing
to happen when you run the "emacs" or "xemacs" commands.

Quote:> 5. The /etc/rc[0123456].d/ dirs are filled with symlinks pointing to
>    /etc/init.d/, instead of having actual boot scripts, like normal
>    systems do.  Why?

AFAIK a symlink farm is perfectly normal for SysV init.  The idea is
that you only have to modify one copy of the script

--

            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

 
 
 

Qs about debian

Post by Michael Pow » Thu, 30 Sep 1999 04:00:00


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


    >> 1. Why is emacs 19.34 the default emacs when I installed debian
    >> with the `huge development' package?  emacs 19.34 is 3 years
    >> old.

    Mark> Emacs 19 still works perfectly well for a lot of uses - the
    Mark> main tardis (see e-mail address) machine was running it as
    Mark> the default Emacs until relatively recently without user
    Mark> complaints.  Emacs 19 is also required for some Emacs Lisp
    Mark> programs.

Of course, it still works.  And some places may still use it because
of its size.  Nonetheless, emacs 20.3 has been out for more than a
year and it doesn't really make sense to me to treat it as though
there were something wrong with it.

    Mark> I'm not entirely sure why it's the default Emacs, although I
    Mark> suspect that the fact that the disk footprint is 10
    Mark> megabytes smaller has a lot to do with it - many users won't
    Mark> notice the feature differences but will notice the disk
    Mark> space.  I could be wrong, though.

I certainly did.  It broke my .emacs.

    >> 2. Why do I get xdm for a login when I didn't ask for it?

    Mark> You installed the xdm package, which runs xdm by default.
    Mark> Deinstalling the package or fiddling with the init script
    Mark> will stop it running.

Well, I installed it all right, but not because I wanted to.  I wasn't
asked.  I just took the "huge development" option and it was,
apparently, a part of the package.

    >> 3. Why is the default compiler (gcc) version 2.7.2.3?  It's
    >> more than 2 years old.  Should I really believe that that is
    >> the version that debian maintainers are using?

    Mark> It's only the default gcc - the C++ and Fortran compilers
    Mark> are the EGCS ones and is also an egcs package as well which
    Mark> installs the EGCS C compiler as egcc.  Since version 2.0
    Mark> kernel is only guarenteed to work with gcc 2.7.2 and
    Mark> requires some unofficial patches for use with EGCS gcc 2.7.2
    Mark> is the version chosen to provide the gcc command.

This, however, can lead to confusion and error.  The way I found out
about it was by trying to compile a recently-written program which
errored out.  I had compiled this same program on my slackware box
several times so I was quite sure the problem was not with the
source.  I checked into the version of gcc, found "egcc" and compiled
with the latter without a problem.

    Mark> Now that the kernel will build with EGCS and EGCS has become
    Mark> GCC this problem has gone away and the development version
    Mark> of Debian uses one current version of GCC for all the
    Mark> relevant compilers.

Whew.

    >> 4. In my /usr/bin, I have three copies of everything associated
    >> with emacs -- one copy for emacs 19, one for emacs 20, and one
    >> for xemacs.  That makes something like 20 files altogether.
    >> Then, in /etc/alternatives, I have symlinks pointing to each of
    >> these items.  Why?  It's a mess.

    Mark> Well, you did select the *huge* development package.  :-)

True, but the standard development package is supposed to be ~407Mb
and the "huge" development package is ~475Mb and it looks like about
50Mb of that difference is taken up with multiple installs of emacs!

(Another oddity:  the exim documentation is not installed by default,
if you need to make changes to the mailer, you have to go hunt up the
docu.  That makes little sense to me.)

    Mark> I guess the reason for installing them all is that while
    Mark> Emacs 19 is standard developers are more likely to want the
    Mark> more current version and taking sides in the Emacs/XEmacs
    Mark> debate would annoy some people.

emacs 19 is <not> standard.  In fact, it's deprecated.  I'll wager not
even 10% of debian users would look for version 19 if it were not
installed. A good deal of new elisp development will not even work
with version 19.

    Mark> The main reason for the symlinks in /etc/alternatives is
    Mark> that there are multiple binaries for the Emacsen - XEmacs
    Mark> has xemacs20-mule, xemacs20-nomule and
    Mark> xemacs20-mule-canna-wnn versions while both Emacs 19 and
    Mark> Emacs 20 are packaged.  Whichever you have installed (and it
    Mark> is possible you'd want more than one of each) you want the
    Mark> right.  thing to happen when you run the "emacs" or "xemacs"
    Mark> commands.

    >> 5. The /etc/rc[0123456].d/ dirs are filled with symlinks
    >> pointing to /etc/init.d/, instead of having actual boot
    >> scripts, like normal systems do.  Why?

    Mark> AFAIK a symlink farm is perfectly normal for SysV init.  The
    Mark> idea is that you only have to modify one copy of the script

Okay.  Of course, I don't necessarily have to modify only one
script. If I want to make a change in, say runlevel 2, I have to look
through every script in init.d to see if I'm going to break anything
else by doing so.  It would seem like it would be easier if I had a
separate set of scripts for runlevel 2.

Thanks for the information, I appreciate it.

mp

     ------------------------------------------------------------
        "Language is the dress of thought."  -- Samuel Johnson
- --

Portland, Oregon USA                       http://www.trollope.org
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v0.9.8 (GNU/Linux)
Comment: Mailcrypt 3.5.3/GnuPG v0.9.8 http://www.gnupg.org

iD8DBQE38mgp755rgEMD+T8RAmwmAJ9WGFw/cAbEi63qKP2cCPNRUUdUeACePcAF
KpXO9Z7RiTgJJJLIrLQOqmQ=
=8s69
-----END PGP SIGNATURE-----

 
 
 

Qs about debian

Post by Paul Kimo » Thu, 30 Sep 1999 04:00:00



>    >> 5. The /etc/rc[0123456].d/ dirs are filled with symlinks
>    >> pointing to /etc/init.d/, instead of having actual boot
>    >> scripts, like normal systems do.  Why?

>    Mark> AFAIK a symlink farm is perfectly normal for SysV init.  The
>    Mark> idea is that you only have to modify one copy of the script

> Okay.  Of course, I don't necessarily have to modify only one
> script. If I want to make a change in, say runlevel 2, I have to look
> through every script in init.d to see if I'm going to break anything
> else by doing so.  It would seem like it would be easier if I had a
> separate set of scripts for runlevel 2.

The point of using sysv-style init scripts is to facilitate package adding
and removing.  A package has a self-contained init script, and installing
it puts in the symlinks.  Removing it takes out the symlinks.  This is
cleaner than writing a program to edit the BSD-style init scripts.  It is
also more annoying for humans to read.

--

 
 
 

Qs about debian

Post by John Hasle » Thu, 30 Sep 1999 04:00:00


Quote:Michael Powe writes:
> In my /usr/bin, I have three copies of everything associated with emacs
> -- one copy for emacs 19, one for emacs 20, and one for xemacs.  That
> makes something like 20 files altogether.  

The emacs maintainers were afraid someone would be offended if they left an
emacs out.  Just remove the ones you don't want.  
'dpkg --purge emacs19 xemacs20' will do it.

Quote:> Then, in /etc/alternatives, I have symlinks pointing to each of these
> items.  Why?  It's a mess.

man update-alternatives.
--
John Hasler

Dancing Horse Hill
Elmwood, WI
 
 
 

Qs about debian

Post by Christopher Brow » Fri, 01 Oct 1999 04:00:00



>-----BEGIN PGP SIGNED MESSAGE-----
>Hash: SHA1



>    >> 1. Why is emacs 19.34 the default emacs when I installed debian
>    >> with the `huge development' package?  emacs 19.34 is 3 years
>    >> old.

>    Mark> Emacs 19 still works perfectly well for a lot of uses - the
>    Mark> main tardis (see e-mail address) machine was running it as
>    Mark> the default Emacs until relatively recently without user
>    Mark> complaints.  Emacs 19 is also required for some Emacs Lisp
>    Mark> programs.

>Of course, it still works.  And some places may still use it because
>of its size.  Nonetheless, emacs 20.3 has been out for more than a
>year and it doesn't really make sense to me to treat it as though
>there were something wrong with it.

There is, if you're trying to run those Elisp programs that have not
been modified to play well with 20.3...

Quote:>    >> 2. Why do I get xdm for a login when I didn't ask for it?

>    Mark> You installed the xdm package, which runs xdm by default.
>    Mark> Deinstalling the package or fiddling with the init script
>    Mark> will stop it running.

>Well, I installed it all right, but not because I wanted to.  I wasn't
>asked.  I just took the "huge development" option and it was,
>apparently, a part of the package.

Arguably this should be a more visibly selectable option; the
"pro argument" goes something like:

  "If you're installing X, wouldn't you want to start X by default?"

- Show quoted text -

Quote:>    >> 3. Why is the default compiler (gcc) version 2.7.2.3?  It's
>    >> more than 2 years old.  Should I really believe that that is
>    >> the version that debian maintainers are using?

>    Mark> It's only the default gcc - the C++ and Fortran compilers
>    Mark> are the EGCS ones and is also an egcs package as well which
>    Mark> installs the EGCS C compiler as egcc.  Since version 2.0
>    Mark> kernel is only guarenteed to work with gcc 2.7.2 and
>    Mark> requires some unofficial patches for use with EGCS gcc 2.7.2
>    Mark> is the version chosen to provide the gcc command.

>This, however, can lead to confusion and error.  The way I found out
>about it was by trying to compile a recently-written program which
>errored out.  I had compiled this same program on my slackware box
>several times so I was quite sure the problem was not with the
>source.  I checked into the version of gcc, found "egcc" and compiled
>with the latter without a problem.

>    Mark> Now that the kernel will build with EGCS and EGCS has become
>    Mark> GCC this problem has gone away and the development version
>    Mark> of Debian uses one current version of GCC for all the
>    Mark> relevant compilers.

>Whew.

That's a mouthful, but if you ask the question "Why?" this is the
necessary answer.

The length and complexity of the explanation, as well as the bountiful
number of 'possibly required compiler versions' displays how
dramatically bad a thing it is for a complex system like GCC to go
through a "code fork."

The worst of it is over now as the code bases have joined back
together as "EGCS is now becoming GCC."

It may be six months yet before that filters down to all the
software...

Quote:>True, but the standard development package is supposed to be ~407Mb
>and the "huge" development package is ~475Mb and it looks like about
>50Mb of that difference is taken up with multiple installs of emacs!

It wasn't required to make sense :-).

Quote:>(Another oddity:  the exim documentation is not installed by default,
>if you need to make changes to the mailer, you have to go hunt up the
>docu.  That makes little sense to me.)

That's a bit odd.

Quote:>    Mark> I guess the reason for installing them all is that while
>    Mark> Emacs 19 is standard developers are more likely to want the
>    Mark> more current version and taking sides in the Emacs/XEmacs
>    Mark> debate would annoy some people.

>emacs 19 is <not> standard.  In fact, it's deprecated.  I'll wager not
>even 10% of debian users would look for version 19 if it were not
>installed. A good deal of new elisp development will not even work
>with version 19.

There's probably some critical package that someone worries about that
doesn't work with version 20; I'll not claim to know what...

Quote:>    >> 5. The /etc/rc[0123456].d/ dirs are filled with symlinks
>    >> pointing to /etc/init.d/, instead of having actual boot
>    >> scripts, like normal systems do.  Why?

>    Mark> AFAIK a symlink farm is perfectly normal for SysV init.  The
>    Mark> idea is that you only have to modify one copy of the script

>Okay.  Of course, I don't necessarily have to modify only one
>script. If I want to make a change in, say runlevel 2, I have to look
>through every script in init.d to see if I'm going to break anything
>else by doing so.  It would seem like it would be easier if I had a
>separate set of scripts for runlevel 2.

<gingerly-criticizing>
I'd think you have the method backwards...
</gingerly-criticizing>

If you go in and modify /etc/init.d/, then you "clearly must intend"
to mess with anything that runs that script, in *all* runlevels.

If, in contrast, you want to merely mess with runlevel 2, 'twould be
appropriate to go into /etc/rc2.d/, and break the symbolic link to
/etc/init.d/.

This of course means that once you've "broken" the link, you'd have to
take some explicit action to "fix" it back up if, down the road, you
wanted to modify the event and hit all runlevels including 2...  But
that would be a given anyways...

[aside: The fact that neither BSD nor SYSV init schemes are
unambiguously perfect are why some people have started looking at
alternatives, such as david parsons' "init" for ``Mastodon;''
apparently some Debian folk are also looking at a successor to their
init that would have all config in one file in similar fashion...]
--
"This .signature is shareware.  Send in $20 for the fully registered
version..."

 
 
 

Qs about debian

Post by John Hasle » Fri, 01 Oct 1999 04:00:00


Quote:Michael Powe writes:
> Of course, I don't necessarily have to modify only one script. If I want
> to make a change in, say runlevel 2, I have to look through every script
> in init.d to see if I'm going to break anything else by doing so.  It
> would seem like it would be easier if I had a separate set of scripts for
> runlevel 2.

man update-rc.d
--
John Hasler                This posting is in the public domain.

Dancing Horse Hill         Make money from it if you can; I don't mind.
Elmwood, Wisconsin         Do not send email adverti*ts to this address.
 
 
 

Qs about debian

Post by John Hasle » Fri, 01 Oct 1999 04:00:00


Quote:Christopher Browne writes:
> aside: The fact that neither BSD nor SYSV init schemes are unambiguously
> perfect are why some people have started looking at alternatives, such as
> david parsons' "init" for ``Mastodon;'' apparently some Debian folk are
> also looking at a successor to their init that would have all config in
> one file in similar fashion.

Debian includes the package 'file-rc':

  Alternative one-configfile boot mechanism

  This package provides an alternative mechanism to boot the system and to
  shut it down.  The /etc/rc?.d links will be converted into one single
  configuration file /etc/runlevel.conf instead, which is easier to
  administrate than symlinks, and is also more flexible.  The package will
  automatically convert your existing symlinks into the file method on
  installation, and convert the file back into symlinks on removal.  Both
  mechanism are compatible trough /etc/init.d/rc, /etc/init.d/rcS and
  /usr/sbin/update-rc.d scripts.
--
John Hasler                This posting is in the public domain.

Dancing Horse Hill         Make money from it if you can; I don't mind.
Elmwood, Wisconsin         Do not send email adverti*ts to this address.

 
 
 

Qs about debian

Post by Mark Brow » Sat, 02 Oct 1999 04:00:00


[Emacs defaulting to version 19]

Quote:> There is, if you're trying to run those Elisp programs that have not
> been modified to play well with 20.3...

The people to ask if you really want to know are the relevant
maintainers.  I'm just guessing.

Quote:> >    >> 2. Why do I get xdm for a login when I didn't ask for it?
> >    Mark> You installed the xdm package, which runs xdm by default.
> >    Mark> Deinstalling the package or fiddling with the init script
> >    Mark> will stop it running.
> >Well, I installed it all right, but not because I wanted to.  I wasn't
> >asked.  I just took the "huge development" option and it was,
> >apparently, a part of the package.
> Arguably this should be a more visibly selectable option; the
> "pro argument" goes something like:
>   "If you're installing X, wouldn't you want to start X by default?"

There's also the "you're taking a standard list of packages, so you
get whatever we choose".

Quote:> >    >> 3. Why is the default compiler (gcc) version 2.7.2.3?  It's
> >    >> more than 2 years old.  Should I really believe that that is
> >    >> the version that debian maintainers are using?
> >    Mark> It's only the default gcc - the C++ and Fortran compilers
> >    Mark> are the EGCS ones and is also an egcs package as well which
> >    Mark> installs the EGCS C compiler as egcc.  Since version 2.0
> >    Mark> kernel is only guarenteed to work with gcc 2.7.2 and
> >    Mark> requires some unofficial patches for use with EGCS gcc 2.7.2
> >    Mark> is the version chosen to provide the gcc command.
> >This, however, can lead to confusion and error.  The way I found out

It does - the situation sucked, and has thankfully been rectified.
All the distributions that I know about shipped with all the latest
goodies while kernel 2.0 and EGCS were both current had a hack like
this[1], it's just that Debian is the only one which hasn't released
since then.

Sometimes ultra-stability sucks.

Quote:> It may be six months yet before that filters down to all the
> software...

Since Debian appears to be the only distribution left with kernel 2.0
so the main problem is mostly already gone - the output of gcc
--version doesn't really matter, but the multiple versions of gcc
does.

Quote:> >(Another oddity:  the exim documentation is not installed by default,
> >if you need to make changes to the mailer, you have to go hunt up the
> >docu.  That makes little sense to me.)
> That's a bit odd.

Bugged me too, although the configuration script seems to have ironed
out most of the common complaints by now.  Seems like someone ought to
submit a wishlist bug about this.

Quote:> >    Mark> I guess the reason for installing them all is that while
> >    Mark> Emacs 19 is standard developers are more likely to want the
> >    Mark> more current version and taking sides in the Emacs/XEmacs
> >    Mark> debate would annoy some people.
> >emacs 19 is <not> standard.  In fact, it's deprecated.  I'll wager not
> >even 10% of debian users would look for version 19 if it were not
> >installed. A good deal of new elisp development will not even work
> >with version 19.

I'd wager that an even higher percentage of users don't care either
way, but what would I know :-) .  Like I said, ask the maintainers.

Quote:> There's probably some critical package that someone worries about that
> doesn't work with version 20; I'll not claim to know what...

The packages custom, emacs-czech, rememberance-agent and vm in Slink
all depend emacs19 without providing the option of another Emacs.

[rc.d]

Quote:> >Okay.  Of course, I don't necessarily have to modify only one
> >script. If I want to make a change in, say runlevel 2, I have to look
> >through every script in init.d to see if I'm going to break anything
> >else by doing so.  It would seem like it would be easier if I had a
> >separate set of scripts for runlevel 2.
> <gingerly-criticizing>
> I'd think you have the method backwards...
> </gingerly-criticizing>

No, I'm just not explaining very well.  In fact, I don't understand
what I was talking about there at all.  Apparently, I need to release
Usenet posts less early and less often.

Quote:> If you go in and modify /etc/init.d/, then you "clearly must intend"
> to mess with anything that runs that script, in *all* runlevels.

Quite.

Quote:> If, in contrast, you want to merely mess with runlevel 2, 'twould be
> appropriate to go into /etc/rc2.d/, and break the symbolic link to
> /etc/init.d/.

I find that this is so uncommon I've never done it - when I've wanted
to change an init script, it's been in a way that applies to all
runlevels.  Having one copy of the script means the change only needs
to be made once.

If I did want something different I'd probably create a new script in
init.d to avoid confusion - the two versions would be controlling
different services.

Quote:> [aside: The fact that neither BSD nor SYSV init schemes are
> unambiguously perfect are why some people have started looking at
> alternatives, such as david parsons' "init" for ``Mastodon;''
> apparently some Debian folk are also looking at a successor to their
> init that would have all config in one file in similar fashion...]

We are?  Any references (not disbelief - more curiosity.  I know about
the discussion on -devel at the minute but I'll wait for code or at
least a nice spec before I get e*d about something happening)?

The only thing I'm aware of that seems relevant is the proposals for a
better way of handling all the questions you get asked during package
installation which would allow questions to be presented through
whatever interface you like.  This would allow fancy GUIs and
automatic setup with configuration downloaded over a network or taken
from a config file.  One nice-looking system (probably the one which
will get used) just got an initial release, so will probably be in at
least quite wide use by the release after next.

[1] Actually, now that I think about it Madrake may not have, but they
    use PGCC where the official attitude to Linux kernel compatibility
    issues is basically "unless you can point out a definite bug in PGCC
    and preferrably provide a patch we don't have the time or enthusiasm
    to care.".

--

            http://www.veryComputer.com/~broonie/
EUFS        http://www.veryComputer.com/

 
 
 

Qs about debian

Post by Mark Brow » Sat, 02 Oct 1999 04:00:00




> > Okay.  Of course, I don't necessarily have to modify only one
> > script. If I want to make a change in, say runlevel 2, I have to look
> > through every script in init.d to see if I'm going to break anything
> > else by doing so.  It would seem like it would be easier if I had a
> > separate set of scripts for runlevel 2.
> The point of using sysv-style init scripts is to facilitate package adding
> and removing.  A package has a self-contained init script, and installing
> it puts in the symlinks.  Removing it takes out the symlinks.  This is
> cleaner than writing a program to edit the BSD-style init scripts.  It is
> also more annoying for humans to read.

That's orthogonal to what he seems to be suggesting.  He seems to want
to be able to have the scripts able to do differnet things in
different runlevels, which is perfectly doable with a package manager
- you simply install a copy into each directory, rather than symlink
around.

There are a couple of problems with this.  One is that if you modify
the actions taken in one runlevel while leaving the service running in
other levels then your system will behave differently depending upon
the order in which you use runlevels - if a service is running in two
runlevels, init won't touch it when you change between them.

The other problem is that it breaks the model.  The idea with SysV
style inits is that you have a bunch of services, and the runlevel
control which set of services is running.  If you want to do different
things in different runlevels, then that means that they're not all
the same service, they're several different services and you should
probably have a seperate init script for each.  The fact that the
services tend to be named after programs could be a bit misleading.

--

            http://www.tardis.ed.ac.uk/~broonie/
EUFS        http://www.eusa.ed.ac.uk/societies/filmsoc/

 
 
 

Qs about debian

Post by Grega Breme » Sat, 02 Oct 1999 04:00:00



> He seems to want to be able to have the scripts able to do differnet things
> in different runlevels, which is perfectly doable with a package manager -
> you simply install a copy into each directory, rather than symlink around.

Hi, all.

There is a simpler to what you suggested, Mark - it looks a bit like this:

case "$0" in
    /etc/rc.d/rcX.d/*)
        {do things for runlevel X}
    ;;
esac

If I'm correct, this also eliminates the two problems you exposed.

Cheers,
        Grega

-----------------
        Grega Bremec
        Vrbnje 60
        4240 Radovljica
        Slovenija
        +386 64 710 267
        ---------------------------

 
 
 

1. Two Debian 2.0 Qs

I just installed Debian 2.0.
1) what are the floppy drives that are designated with letter 'u'?
2) what is the proper total shutdown procedure?  if I do 'shutdown -t
now' it take me to the maintenance prompting me to enter super user
password......
3) how do I change run-level in debian?  is there any utility or
something?  I ask this because when I tried Debian last time which was
about 6 months ago, the run level related things were TOTALLY
different from descriptions in the Linux books that I have.

TIA!
-----

                                                ^
(Remove third letter from word 'motivation', to get the e-mail
address.)

2. Telephony solution for linux

3. Debian v Slackware (rc.d doesn't exist in Debian)

4. start kde as user

5. How do I insert partitions BEFORE my Debian boot partiton and still get Debian to boot?

6. Share Memory Error

7. Debian and proprietary software (Debian folks: please read.)

8. Mach64 and SVGAlib

9. Debian Donations from KDE/Debian CD

10. My Debian! (Debian 2.0 hamm)

11. Debian 1.3 Beta Test, and other Debian News

12. How I upgraded to debian-stable (potato) to debian-testing (woody)