localpkg script changes

[Oliver Eikemeier]

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.


> 2. Starting base rc.d and ports rc.d scripts together from /etc/rc:
>  The last patch in the PR seems to be a fairly practical way of doing
>  this, but would require some broader discussion. I'm also a little
>  uncomfortable about it because mixing in ports daemons with base system
>  daemons in a way that is not deterministic at startup may have security
>  implications. It's fairly
>  easy for an administrator to audit the base system startup order, but
>  when you start introducing ports (third party applications of varying
>  quality) into the mix it becomes a lot harder to know if you are 
> introducing
>  a source of insecurity. This may or may not be a valid concern, but 
> this
>  close to 5-STABLE I think we should hold off on it. In anycase I think
>  this is a separate issue and should be dealt with separately.

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.

I think this would bring us some desperately needed features, while 
`fixing' the ports scripts is a lot of work without added benefits.

-Oliver