Anybody working on removing sendmail from base?

[Mike Porter]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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 
'code bloat'

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 
distfile -state. 

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...

mike
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (FreeBSD)

iD8DBQE/dpHWY30jZzkECLcRAv3aAKCxjx2A6vU1HPfi//WWPSU4GPaS6ACgwV5a
2r1c+cj986A78U9JXTau+3M=
=3VGj
-----END PGP SIGNATURE-----