Date: Fri, 16 Jul 2004 17:41:12 +0300 From: Mike Makonnen <mtm@identd.net> To: Oliver Eikemeier <eikemeier@fillmore-labs.com> Cc: freebsd-rc@freebsd.org Subject: Re: localpkg script changes Message-ID: <20040716144112.GA10133@rogue.acs-et.com> In-Reply-To: <7B900F95-D70F-11D8-8DBE-00039312D914@fillmore-labs.com> References: <20040715150739.GA11628@rogue.acs-et.com> <7B900F95-D70F-11D8-8DBE-00039312D914@fillmore-labs.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Jul 16, 2004 at 12:04:10PM +0200, Oliver Eikemeier wrote: > Mike Makonnen wrote: > > >1. Ports startup scripts breaking: > > [...] > > As I see it now, ports scripts *are* broken because, among other > > things, they expect .sh scripts to be sourced in a sub-shell. [...] > > As far as I am concerned rc.d behaviour is that .sh scripts are > > sourced in the current shell, and others in a subshell. All scripts, > > be they base or ports should follow this behaviour. To have > > inconsistent behaviour between base and ports scripts is a > > bug IMO. The PR you cited mentioned something about changing the > > suffixes, but I think that would be a gratuitous digression from > > behaviour in NetBSD. > > > > In short: current ports scripts behaviour is broken and should be > > changed as soon as possible instead of trying to patch rc.d/localpkg > > to accept and propagate their brokeness through 5-STABLE. > > AFAICS fews scripts in /etc/rc.d use the sourcing mechanism. Your > definition of brokeness seems very NetBSD centric too me, how about > using a different extension on FreeBSD (.src for sourced rc :) ) and > adding a `case' depending on OS to the mechanism? NetBSD could even > merge this, when they want to. I can assure you that you open a major > can of worms when you try to `fix' all FreeBSD ports, including > introducing an incompatibility with 4.x. > The rc.d style ports scripts' behaviour diverge from that of base system rc.d scripts. The main culprit is not enough communication among rc.d developers and ports developers. That does not mean that we should change the relatively stable/expected behaviour of rc.d to accomodate ports rc.d behaviour which is still in a relative state of flux. I'll bring this up with re, and portmgr, and see what they have to say. > I think we should introduce this before 5-STABLE, especially since the > current estimated time frame gives us enough room for testing. If you > want to follow the NetBSD way, you have to add racoon, ports ppp daemons > and other port startup scripts to /etc/rc.d, which IMHO makes no sense > of FreeBSD. This is something that enables to use port features from the > base system, replace base system functionality by ports or even move > parts of the base to ports without any negative impacts. Besides, we > finally have a way to get a proper startup order for ports scripts > without using `000.'. It should be easily possible to either require a > special keyword for ports scripts to get sorted before a certain point, > or assure that most scripts are started after most of the base is up. It's not as simple as that. Besides the security implications there are also many possible corner cases. To name just a couple: diskless, / (root partition), /usr/local, /usr/X11R6 on different partitions or even mounted remotely, etc... How is rc(8) going to handle all these possible scenarios. It's possible, but it's not trivial. And this close to 5-STABLE is not the time to start experimenting with it. If you feel otherwise, then separate this particular issue out from your patch and post to -arch. P.S. - STOP TRIMMING FREEBSD-RC OUT OF THE CC LIST! 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 !
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040716144112.GA10133>