Subject: Re: CVS commit: src/libexec/httpd
To: Mindaugas R. <rmind@NetBSD.org>
From: Julio M. Merino Vidal <jmmv84@gmail.com>
List: source-changes
Date: 10/16/2007 23:52:56
On Oct 16, 2007, at 8:35 PM, Mindaugas R. wrote:

>> Module Name:	src
>> Committed By:	tls
>> Date:		Tue Oct 16 01:14:07 UTC 2007
>>
>> Update of /cvsroot/src/libexec/httpd
>> In directory ivanova.netbsd.org:/tmp/cvs-serv29605
>>
>> Log Message:
>> Import of bozohttpd for its originally intended purpose: a small  
>> (~30k)
>> simple run-from-inetd httpd suitable for small systems (and some  
>> large
>> ones).
>
> Why it was not discussed on <tech-userlevel> and/or other mailing  
> lists? Why
> pkgsrc is not enough?

While I think there should have been some discussion (or at least an  
announcement) in a public list, I don't think the change is incorrect  
per se.  We already ship with tons of daemons in the base system, so  
why can't we have a httpd in it too, given that a http service is a  
very, very common one?  Another one doesn't hurt, and makes a NetBSD  
system more functional out of the box.  (Remember that NetBSD is  
always advertised as being a complete OS -- unlike that other one  
that we all know very well -- and you should expect to get a sane and  
decent amount of functionality from it without additional tweaking.)

> I do not think it is a good way to import such applications into  
> the base
> source tree, at least while there is no appropriate support for  
> syspkgs.

syspkgs are not a reason for not importing new programs, among other  
things because they are not fully functional yet.  We'd argue about  
some components being or not in the base system forever, as there  
currently is no way to easily remove any of them.  I don't see httpd  
is special in this regard, more so after having seen that this  
specific daemon was written explicitly for NetBSD.

E.g. why am I forced to have, for example, lpd in my machine when I  
_never_ use it?  Same can be said for any other service, tool,  
library, whatever, that is currently in the system.

-- 
Julio M. Merino Vidal <jmmv84@gmail.com>