Re: Anybody working on removing sendmail from base?

[Mike Porter <mupi@xxxxxxxxx>]

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

On Monday 29 September 2003 08:25 am, Justin C. Sherrill wrote:

> Instead of worrying about what path is being taken, and so on, it may be
> better to keep the system compiler, languages, etc. completely hidden from
> the user, perhaps with the VFS material Matt is talking about.  i.e. a
> system that has not had the gcc/tendra/Intel compiler port installed has no
> compiler at all, as far as the user is concerned.
>
> Otherwise, you could have each port developer trying to coordinate their
> port compiling with both the 'shipped' system compiler plus whatever is in
> ports, which may be changing.  It would be helpful to remove one of those
> from the equasion.  This carries through to other software that people
> upgrade or change - Perl, sendmail, shell, etc.

I'm sorry but this seems counterproductive.   If there is going to be a perl 
and a cc on the system, even if it is old an outdated, it is a waste of 
bandwidth to force users to install one.  Especially in the case where you 
are installing, say, a gcc, which is exactly the same as the system version.  
This wastes bandwidth for the installation process, as well as disk space in 
having two of the same program installed.  In addition to that, it doesn't 
help to resolve the issue where user A wants one version, and user B wants a 
different version.  

I really like the suggestion of variant symlinks (that particular thought had 
never occurred to me in suggesting the use of a wrapper), since that can make 
cc directly dependent on the environment, and by correctly setting the 
environment in a Makefile, you can force whichever version you need (although 
the case could exist where you try to specify a non-existant (or 
non-installed) version, and logic should be provided to deal with that, if it 
is going to be truly transparent).  It would even allow (although I am not 
certain why we might want to do this, but we could, in fact if we wanted to) 
a gradual migration of the system compiler to a different version, as the 
makefiles for the various parts of the system could eaily be updated to use a 
newer version of gcc (assuming there is a good reason to do this, such as 
faster code execution or better optimization from the newer version), without 
affecting the rest of the system.  As bits and pieces of the system get 
upgraded to use the newer versions, eventually, the whole system would be 
compiled using the newer version....just a random thought--probably not a 
very good one at that, since it makes a buildworld dependent on more than one 
version of cc...

the whole point of the exercise (i thought) was to make it so that a porter 
(aka port developer) does not *need* to try to make a program that was 
written for gcc 3.4 compile on gcc 2.95.4, which happens under FBSD.  You can 
use a port dependency to ensure that gcc 3.4 is installed on the system, 
without worrying about the installation interfereing with the system's use of 
2.95.  Ditto with perl.  This would greatly reduce the amount of patching 
necessary to make a port work, and a lot more programs would 'just work' 
right our of the box, without needing any patching at all.   If porting is 
easier, logic suggests that more programs would tend to be ported, becuase 
each porter could do more programs, and more people could do porting.  Can 
someone explain why THAT is bad?

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

iD8DBQE/eHW7Y30jZzkECLcRAtJhAJ4uyfgD6lbZ57Z2sV2lFn4Dini4BQCfbmEw
rk6miGvi2BIcBv4+0CXKWDg=
=1QXZ
-----END PGP SIGNATURE-----