DragonFly kernel List (threaded) for 2003-09
Re: Anybody working on removing sendmail from base?
-----BEGIN PGP SIGNED MESSAGE-----
On Saturday 27 September 2003 01:55 pm, Matthew Dillon wrote:
> Ick. Maybe /etc/rc.d/cc could be responsible for setting up the
> 'default' compiler for the system by creating a symlink or a VFS alias,
> but we are certainly not going to symlink a high performance program to
> a shell script! :-)
I see your point. Clearly, you can't really replace gcc with a script, what I
was thinking of was something along the lines of a program that could scan
your environment, and determine from this which version (from all available
versions) of (g)cc to use for a particular job. So your Makefile would
define KERNEL_BUILD, and some part of the system (maybe this ties with the
VFS stuff, more than a shell script) recognizes that for a kernel build, we
need gcc X, so cc works correctly.
I guess using cc= in the Makefile would work (probably better than my
solution). the advantage to doing that would be that a porter could specifiy
a version of gcc to use, which might make porting less work, in some cases.
Ditto with similar features for perl, although having 25 different versions
of perl and gcc haning around for port builds gives a new definition for
I was trying to think of a way that the selection of which cc to use would be
completely transparent to the end user, ie, you always type 'cc' but which
version you get depends on the build environment. If you are just running cc
from the command line, it defaults to the latest version, but running from a
buildworld, it uses the 'system' version.
> I think what we want is a feature similar to build-to-order, which I
> believe does exist in the current ports system. Basically a list of
> those packages we want to include in our 'custom' build.
> I'd actually prefer to make something like this the default... so
> instead of a 'make' or 'make clean' in a high level ports directory
> messing with the entire subtree, it would instead just mess with
> designated packages.
Some of this begins to cross back over to the territory of the package
management system. For my money, I would like to see a mechanism for certain
ports to be built automatically during buildworld (for example, the nvidia
driver, which frequently breaks on kernel updates) (and the port should have
the intelligence to add itself to the 'critical' list automatically, or at
least by confirmation only (I can see porters abusing this)). Other ports,
including some stuff currently built as part of the world, like BIND and
sendmail (even, most likely, gcc and perl, which by the time they make it to
be the 'standard' version, are not likely to be changing much, if at all)
could be dropped from the normal build process (which would greatly speed
things up, I should think) (perhaps with (tied into the package manager,
again) some sort of compile_if_updated flag. (ie, gcc has a secutiry fix,
we'd want to rebuild before our next world, but if not, why bother? Its a
waste of CPU cycles at best (and after all, doesn't SETI need those? <(}:) )
I'd think we'd want a couple of layers in this sort of priority (for example,
certain 'critical' bits like sendmail (or default mta, to expand this a bit,
since we are, after all, talking about making sendmail not part of the base,
and instead allowing any mailer to plug in)) we'd have to be sure are always
there, regardless of where 'make clean' is invoked) however, unless there
are changes to the code (and even then, in some cases) we don't need to
update the default mta when building world. By contrast, a package such as
X, we probably don't need the source for all the time, unless we have a slow
computer and lots of hard drive space--but I like the idea that you could
configure it either way.
I guess it is also worth pointing out that 'make clean' in ports removes all
the workfiles, where 'make clean' in /usr/src/sys removes stale compiles
files, but doesn't touch the actual source (*.c, *.h) files. Maybe we need
something like that, instead, with a 'distclean' option for reverting to the
Finally, this does leave a few unanswered questions, like, how does a port
determine if it is 'system critical' and needs to preserve the source? In
the case of mtas, is this configured from /etc/rc.d/mail, which sets the
default mta? This makes sense, but how does a port of gcc know if it is the
system critical version or not?
well, enough pontificating and pondering for the night. One of these days I'm
going to have to learn to do something more useful than contributing ideas...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)
-----END PGP SIGNATURE-----