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_at_identd.net | Fingerprint: AC7B 5672 2D11 F4D0 EBF8 5279 5359 2B82 7CD4 1F55 mtm_at_FreeBSD.Org| FreeBSD - Unleash the Daemon !Received on Sat Jul 31 2004 - 12:55:50 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:04 UTC