Anybody working on removing sendmail from base?

Justin C. Sherrill justin at shiningsilence.com
Mon Sep 29 13:10:07 PDT 2003


Mike Porter wrote:

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

The bandwidth waste seems minimal, given that disk space is plentiful, and
most everyone installs ports anyway.  Would the minor amount of disk space
used be worse than having to deal with outdated system parts?

Besides, if we are using variant symlinks to allow software to be built
using particular versions of a compiler|interpreter|library, wouldn't that
end up bringing in multiple versions of software anyway?  

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

That was my concept; keep the system-required utilities separate so that
users and porters cannot access them, and instead they track only the
appropriate port for the system.  This doesn't prevent the use of variant
symlinks for different versions of software on the system.

My entire goal with this suggestion is to avoid any sort of user dependency
on the installed third-party tools.  Even if my suggestion isn't the way to
do it, I'd like if there was some sort of enforced separation.  I'm
assuming a DragonFly system will eventually have some chunk of system
software (perl, gcc, etc) out of date, and I wouldn't want anything in
ports (or any other user work) dependent on it.






More information about the Kernel mailing list