Why is sendmail is part of the system and not a package?

[Gonzalo Nemmi]

On Tuesday 27 October 2009 4:00:07 pm Giorgos Keramidas wrote:
> On Tue, 27 Oct 2009 15:43:39 -0200, Gonzalo Nemmi <gnemmi at gmail.com> 
wrote:
> >On Tuesday 27 October 2009 7:32:14 am b. f. wrote:
> >>>It's in /usr/sbin/sendmail.
> >>>
> >>>How many people actually use it? Very few.  Why isn't it moved to
> >>>ports?
> >>
> >> Obviously, not everyone wants or needs sendmail in the base
> >> system. But quite a few people do use it, and many FreeBSD
> >> developers are happy with the status quo, so it is unlikely that
> >> sendmail will be removed soon.  But there's nothing to prevent you
> >> from disabling it in rc.conf(5):
> >
> > Or from switching to other BSDs in which the last word over an
> > issue stands in the hands of reason .. and not in the hands of
> > status quo... which, by the way, never took any science a single
> > step forwar, and on the contrary ... did everything it could to
> > stop it ... because otherwise, there would be no status quo anymore
> > or it will fall in the hands of others.
>
> This is precisely the reason why the `status quo' exists.  Because
> people tend to get all political about this sort of thing, and that's
> exactly the point where the entire discussion goes downhill.

So .. status quo is a good thing ...

> First of all, there are ways to build a base system _WITHOUT_ any
> trace of Sendmail (the WITHOUT_SENDMAIL, WITHOUT_MAILWRAPPER and
> WITHOUT_MAIL) knobs.  So it's not like FreeBSD stops anyone from
> removing Sendmail.

That was never the OP's concern and it's a point that has already been 
clear for ages and then some more.
  
> Now, the rest of the comments about 'science' and 'moving forward'
> are not productive at all.  If someone wants to move the particular
> thing forward there is a well-known _technical_ way of resolving
> this:

Yet, CS development takes place on BSD fields .. so ... I beg to 
disagree but, AFAIC the only thing that's not productive at all is not 
discussing issues and let them be handled by  "status quo", which .. 
yet again, never took and any science a single step forward.
Feel free to read any history book that accounts from Galileo to today.


>   - Import your MTA of choice in a local branch.
>   - Integrate the $NEWMTA with the base system of FreeBSD.
>   - Update the manpages and documentation for $NEWMTA.
>   - Submit the patches to the FreeBSD team for review.
>   - Keep updating them as FreeBSD changes.
>   - Maintain and keep the $NEWMTA in shape, by:
>       + reimporting new releases
>       + fixing any bugs that creep up
>       + answering questions of the people who are in a (painful)
>         transitional phase while the dust from $NEWMTA import settles
>       + showing that you have a genuine interest to keep $NEWMTA in a
>         functional, up to date, working condition
>
> This is a *lot* of work.  Don't be fooled into thinking that I am
> ever implying it's going to be easy.  It will take time, patience, a
> _lot_ of effort on the part of the submitter, and a sizable amount of
> _time_.

That's way outside of the scope of the OP question .. yet still:

Wasn't ZFS (and isn't) a lot of work?
Aren't DMA, OpenSMTP, OpenCVS, ULE a lot of work?
Weren't OpenSSH, OpenSSL, SMP support a lot of work?

Actually, I really have a hard time looking for something that wasn't, 
isn't, or will be a *lot* of work.

Maybe we could ask Ed Schouten if his xterm-style emulator will or will 
not be a *lot* of work .. like to have an authoritative answer ...

And since we are at it, wasn't translating the whole FreeBSD 
documentation into greek a *lot* of work Giorgos. Maybe you could 
provide us with an authoritative answer too.

What wasn't that didn't stop you from doing it??

> But it is not impossible.  So, anyone who really _wants_ to do it, is
> really both welcome to go ahead and certainly free to do it.

Given the state of the "status quo" .. I really doubt anyone will stand 
up to take that task into his hands .. even if as a GSOC.

Best Regards
Gonzalo Nemmi