Re: Anybody working on removing sendmail from base?

[Mike Porter <mupi@xxxxxxxxx>]

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

On Friday 26 September 2003 12:39 pm, Matthew Dillon wrote:
>     The way I envision mail replacement is to create an 'API' through
>     an RCNG script which 'mail system ports' would have to conform to.
>
<snip>

>     This is just an example of how it could work.  In anycase, this would
>     provide a migration path for sendmail to leave the base system because
>     the RCNG support could be worked on right now, without removing
> sendmail, then the sendmail port could be modified to use the new API and
> tested (by using mta_sendmailXXX_* RC variables and turning off the base
> sendmail with the original RC variables), and then as a final step sendmail
> could be removed from the base system).

This same framework could be used for other stuff (bind) and more significant 
bits as well, such as gcc and perl.  The fun thing in those cases would be 
ensuring that, e.g., /usr/bin/cc is symlinked to /etc/rc.d/cc, to determine 
the correct CC to run (you don't want to compile the kernel with the wrong 
version of gcc, it might not work, which is probably why the other BSDs 
included it in the base system, while making ports available for newer 
versions.  On the other hand, sometimes it might work, and it would be nice 
to play with it and see)

This  scenario, however does raise another interesting question, applicable to 
the portsng framework:  currently as part of buildworld, gcc, sendmail, etc 
are rebuilt from scratch (which makes sense, since the version of gcc used 
from one version to the next may change)  Does this mean that portsng will be 
rebuilt during buildworld?  Or will only certain parts, the "important bits" 
such as gcc be rebuilt?  Or will we be able to specify which parts to build 
or not build?  I ask this becuase of two potential issues.  First, under the 
current (FBSD) ports system, a 'make clean' removes all files from the ports' 
directory, where buildworld would want the source present to be able to 
rebuild--especially in cases where the port version has changed, but we 
haven't updated, so the source for our version may no longer be available. 
(for example, I usually keep my ports TREE up-to-date, so fetching the 
distfile may not have the version I am expecting--unless we do what FBSD has 
done with gcc and make 6 different versions available in ports).  The other 
problem with simply rebuilding all ports is that then you are looking at, in 
some cases at least, rebuilding a lot of very big ports (Xfree86), which are 
quite time consuming, thus dramatically increasing buildworld time.  I guess 
ideally there would be a way to specify which ports we want to rebuild during 
buildworld.  On the flip side of this is the fact that it probably isn't 
always strictly necessary to rebuild gcc (not to mention sendmail, bind, etc) 
as part of a buildworld, unless we want to update something, or the new 
kernel/world wants a newer gcc--which could be specified in the makefile.

Well, enough rambling for a while....

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

iD8DBQE/dbCXY30jZzkECLcRAiKjAJ9e9tmi06jp64U4EvMllubl15na6gCggN/Y
NgtlJMaUqh7WKId7vDXCYI8=
=tnko
-----END PGP SIGNATURE-----