Subject: Re: CVS commit: src/libexec/httpd
To: Valeriy E. Ushakov <email@example.com>
From: Thor Lancelot Simon <firstname.lastname@example.org>
Date: 10/17/2007 05:27:12
On Wed, Oct 17, 2007 at 07:44:48AM +0400, Valeriy E. Ushakov wrote:
> On Tue, Oct 16, 2007 at 22:51:59 -0400, Thor Lancelot Simon wrote:
> > Small embedded devices are a crucial market for NetBSD. Most of the build
> > environments for those devices are cross-build environments, which is why
> > build.sh has helped NetBSD win over a lot of people and companies working
> > with those environments. Unfortunately, from those people's perspective,
> > pkgsrc just isn't part of NetBSD that they can use, because it cannot,
> > for example, cross build arbitrary packages from amd64 to mips.
> BTW, any program with bsd makefiles (or for that matter any
> well-behaved autoconfed program - but I only really tried gnu hello :)
> can be be built outside of the src tree uisng nbmake wrapper.
Programs with BSD makefiles yes, autoconffed programs no. I've just
spent a couple of weeks buried in this. The problem with autoconffed
programs is usually that they depend on a rats' nest of other autoconffed
programs and eventually you hit either something that uses AC_TRY_RUN
or a library that requires libtool. I have not yet succeed in battering
libtool into working correctly with any kind of cross toolchain, though
generally in these cases I have built NetBSD src/dist style reachacross
Makefiles and generated the required config.h for each of my targets
by hand, so I have not tried very hard to make libtool work right.
I should note, though, that the fact that a program ships with BSD
makefiles isn't necessarily a reason _not_ to ship it as part of the
NetBSD 'src' module; after all, on those grounds, we could tear all
of src apart into a million little .tar.gz files, and require users to
fetch each of them individually to build -- and lose all our CVS history
while we're at it.
I would, however, be in favor of removing some of the obsolete software
(particularly daemons for no longer used network protocols) that we ship,
and generally rationalizing what's in the NetBSD base system. However,
ranting and raving (and I'm not saying this is coming from you) about how
including any program also supplied in pkgsrc in NetBSD base means that
NetBSD is rejecting pkgsrc isn't terribly persuasive to me as an argument
We could remove ftp and ftpd, too, since though the maintainer of the
version we wrote did the work for inclusion in NetBSD, those programs in
their autoconffed clothes are also available in pkgsrc. Should we?
I should note that personally I feel just fine on the bloat score; since
the last release of NetBSD, I have removed a _lot_ more lines of code from
NetBSD's source tree than I've added, including one entire large package
of daemons that was moved to pkgsrc.
So I can feel confident that my contribution has been and will remain
negative, on the balance, and I think others will back me up on this.