Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg)

From: Mike Makonnen (mtm_at_identd.net)
Date: 07/31/04

  • Next message: Arne Schwabe: "Re: Synaptics Touchpad sample port adopted for current's psm.c" 
    Date: Sat, 31 Jul 2004 17:56:16 +0300
To: Oliver Eikemeier <eikemeier@fillmore-labs.com>

    On Sat, Jul 31, 2004 at 03:24:56PM +0200, Oliver Eikemeier wrote:
    > Mike Makonnen wrote:
    >
    >
    > Lets be realistic: Nearly nobody wants his scripts to be sourced in the
    > startup shell, especially not in /usr/local/etc/rc.d. People who really
    > want to do this are experts that exactly know what they are doing, and
    > are not easily confused.

    *sigh* You cannot arbitrarily declare that "nearly nobody wants his
    scripts to be sourced in the startup shell". You have no idea of knowing
    what a user might want to do with his system and what his level of
    expertise is.

    > >>Legacy script were never executed when put in
    > >>/etc/rc.d, and won't after this patch. I can't really follow your
    > >>argument here.
    > >
    > >I'm not talking about legacy scripts. I mean local rc.d scripts.
    >
    > Local rc.d scripts will continue to be executed as before.

    except if they have a .sh extension.

    >
    > I'm not exactly concerned with NetBSD compatibility here, especially
    > considering the facts that (a) rc.subr has already set_rcvar with `case
    > ${OSTYPE}' in it (only in the FreeBSD version, I can't find that in
    > NetBSD), which doesn't exist in NetBSD, (b) The only two scripts with
    > an `.sh' extension (early.sh rcconf.sh) are FreeBSD specific, while the
    > only NetBSD script with an `.sh' extension (bootconf.sh) doensn't exist
    > in FreeBSD. Compatibility with NetBSD seems to be a myth, especially
    > since they never bothered to merge the changes back from FreeBSD.

    I don't mean source code compatibility. I don't really care *too much*
    about that either. What I am concerned with is compatibility
    behaviour-wise.

    >
    > >>>Also, a sysadmin
    > >>>might have a local script in /usr/local/etc/rc.d that may for example,
    > >>>load a different rc.conf depending on circumstances.
    > >>
    > >>{He,She} might, although I consider such a functionality to be exotic
    > >>and fragile. Anyway, /etc/rc.d could be used for that purpose.
    > >
    > >You have no way of knowing what users want to do or what their
    > >circumstances
    > >are. This would be be an instance of enforcing policy instead of
    > >providing mechanisms for users to do what they want.
    >
    > When you have no way of knowing what users want to do, how can you
    > provide mechanisms for them to do so?

    By leaving their options open. By not forcing them to do it one way.

    > (a) I want rc.d scripts in /usr/local/etc/rc.d to behave exactly like
    > they do in /etc/rc.d, namely participate in rcorder(8). This was the
    > most common reason to move scripts from /usr/local/etc/rc.d to /etc/rc.d.

    If ports rc.d scripts with .sh extensions aren't sourced in the same shell,
    then they don't behave "exactly like they do in /etc/rc.d". Participating
    in the boot ordering is not the stick by which the "rc.d'ness" (for lack
    of a better word) of a script is measured.

    >
    > (b) While doing this, I want to keep documented behaviour, so users can
    > keep what worked for them before.

    Correction-- what worked for them in most of 5-CURRENT up to now.

    > We shouldn't break backwards compatibility for no good reason.
    > Compatibility with NetBSD in aspects we never have been compatible is
    > not a good reason to introduce an incompatiblity with -CURRENT.

    We *have* been compatible with respect to behaviour of an rc.d script.
    While we have digressed somewhat by *adding* features, the base behaviour
    is the same.

    Additionaly, compatibility with -CURRENT is not a valid
    excuse for introducing hacks or allowing buggy behaviour to continue.

    >
    > >>>2. Sourcing of ports rc.d scripts with the base sytem scripts to be
    > >>> put behind a knob. If the knob is enabled rc.d/localpkg does not
    > >>> run rc.d scripts in the local_startup directories. If it is turned
    > >>> off, then rc.d/localpkg does ports rc.d scripts in addition to the
    > >>> legacy scripts.
    > >>
    > >>I see no reason why localpkg should do rc.d scripts. It was always
    > >>meant
    > >>to execute old-style scripts, and this behavior shouldn't be changed.
    > >>Why do you want to introduce a semantic split here, that you seem to
    > >>try
    > >>to avoid above?
    > >
    > >This feature MUST be put behind a knob. It
    > >might have been okay if we had discussed this earlier in the 5-CURRENT
    > >lifecycle, but not just before 5-STABLE. We need more time to evaluate
    > >the impact of ordering ports rc.d scripts with the base system scripts.
    > >Two weeks is not enough time.
    >
    > I see absolutely no problems with having this feature now. You wanted
    > similar behaviour of scripts in /etc/rc.d and /usr/local/etc/rc.d, and
    > this is what this patch provides.

    *sigh* No, it doesn't. It hacks rc.d to treat /usr/local/etc/rc.d scripts
    with a .sh extension as old style scripts. That is not the same thing.

    > It is completely backwards compatible,
    > so we don't have to fear breakage. Every new port that starts to
    > participate in rcorder(8) could be tested individually by the maintainer
    > before submitting, so this should be pretty save.

    NO, because it's impossible for the maintainer to test it with even a
    fraction of the possible combinations. Remember that the script has to
    play nice with the scripts as they are currently in /etc/rc.d, with any
    future changes we might have to make to the ordering, with any
    new scripts we might add in the future (or we might have to remove
    a script the script depends on), with current ports rc.d scripts,
    with future ports rc.d scripts, and with any local rc.d scripts
    written by a user. By defenition, it is impossible for a maintainer
    to be absolutely certain that his script will not break something.

    > And we have time for
    > an adequate migration phase, which will help us detect problems. What
    > should be the issues of ordering ports rc.d scripts with the base system
    > scripts, especially when we require that nearly every of them has a
    > `REQUIRE: LOGIN' line? I except very few have the need for something
    > else, but the base will greatly benefit from them.
    >

    1. Not all ports require that they be ordered with the base system scripts. As
       such not all users will benefit from ports being ordered along with the
       base system. It makes sense that these people be able to reduce their
       security exposure by keeping the ports startup order as it is now
       (i.e. somewhat separate from the base system scripts).

    2. This is a major change that requires more than just 2 weeks of testing.
       If it should happen to break something users should be able to turn it
       off.

    >
    > Ah, no: They where relying on documented behaviour in rc(8). localpkg is
    > not buggy, and should not be changed. The scripts are not buggy either,
    > they are simply old-style scripts that source rc.subr and use some of
    > its features. They have never been tested as rc.d scripts, but it should
    > be easy to convert them to become that, since they are pretty similar.
    > Nevertheless one should not be confused of their character because of
    > their similarity to rc.d scripts: they are not, and should not be
    > treated so. Read rc(8) on how they should be handled. What we are trying
    > to do here is to introduce a *new* functionality, which requires new
    > scripts (although they conversion should be easy in most cases).
    >

    Oh please, let's not get into semantic arguments here. If they
    source /etc/rc.subr and implement the functionality that typically
    defines rc.d scripts, then thay are rc.d scripts (or atleast
    they are trying to be).

    And since you brought up rc(8), these rc.d scripts you want to treat
    as old style scripts violate one of the rules of old-style scripts:

         o The output from each script is traditionally a space character, fol-
             lowed by the name of the software package being started or shut down,
             without a trailing newline character (see the EXAMPLES section).

    rc(8) also gives a clear example of what an old-style ports script should
    look like:

         The following is a simple, hypothetical example of an old-style
         /usr/local/etc/rc.d/ script, which would start a daemon at boot time, and
         kill it at shutdown time.

               #!/bin/sh -
               #
               # initialization/shutdown script for foobar package

               case "$1" in
               start)
                       /usr/local/sbin/foo -d && echo -n ' foo'
                       ;;
               stop)
                       kill `cat /var/run/foo.pid` && echo -n ' foo'
                       ;;
               *)
                       echo "unknown option: $1 - should be 'start' or 'stop'" >&2
                       ;;
               esac

    >
    > The only proposal I made in changing the behavior of rc.d is changing
    > the extension to something more well thought out, like `.rc'. Said that,
    > I can live with keeping `.sh' as the extension for sourcing rc.d
    > scripts, although it will do us no good. Anyway, I'm not a big fan of
    > changing documented behavior, be it -CURRENT or not. I think this is a
    > pretty reasonable attitude, but YMMV.

    Ok, can you do the following then:

    1. When you (portmgr) are ready put back the rc.d/localpkg changes
    2. Put the ordering of ports scripts with base system
       scripts behind an rc.conf(5) knob, and modify your patch so both
       /etc/rc and /etc/rc.d/localpkg do the right thing depending on whether
       it's on or off.

    Cheers. 

    -- 
Mike Makonnen  | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
mtm@identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8  5279 5359 2B82 7CD4 1F55
mtm@FreeBSD.Org| FreeBSD - Unleash the Daemon !
_______________________________________________
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"
  • Next message: Arne Schwabe: "Re: Synaptics Touchpad sample port adopted for current's psm.c"

    Relevant Pages

    • Re: freebsd-questions Digest, Vol 184, Issue 3
      ... Starting again from Scratch ... Re: Starting Scripts ... Repopulating the GENERIC kernel ... script to update my ports tree ...
      (freebsd-questions)
    • Re: automake, autoconf compiling
      ... scripts are indeed very platform independent. ... > reason why the FreeBSD ports infrastructure needs to play so many ... the reason the Ports go through all the hoops you see is that they ... One other reason is, of course, the fact that the autotools have changed ...
      (freebsd-newbies)
    • Re: automake, autoconf compiling
      ... scripts are indeed very platform independent. ... > reason why the FreeBSD ports infrastructure needs to play so many ... the reason the Ports go through all the hoops you see is that they ... One other reason is, of course, the fact that the autotools have changed ...
      (freebsd-questions)
    • Re: Primary Differences: FreeBSD/Linux
      ... > shell for scripts, ... Some do, it's in ports. ... ports tree or package tools from a console command line. ...
      (comp.unix.bsd.freebsd.misc)
    • Re: RFC: Alternate patch to have true new-style rc.d scripts in ports (without touching localpkg)
      ... One of the things that I love about FreeBSD is that it doesn't ... Startup scripts are generally the exception on other unixy ... One of the great things about the ports tree was that it installed ...
      (freebsd-current)