Date: Wed, 27 Mar 2002 02:31:42 -0500 From: "Yeasah Pell" <yeasah@apocalypse.org> To: <stable@FreeBSD.ORG> Subject: Re: HEADS UP: sendmail 8.12.2 MFC'ed Message-ID: <026501c1d561$90d61de0$0200a8c0@gauss> References: <200203262226.XAA27664@galaxy.de.cp.philips.com>
next in thread | previous in thread | raw e-mail | index | archive | help
> Karsten W. Rohrbach: > >the question is: why the hell are complex (or rather complicated) > >subsystems that often stay unused still in the base distribution? it is > >simply not consequent, not following the main paradigm of bsd's design, > >to have subsystems like sendmail or bind in the base dist, > > Because they don't ...stay unused. It's just convenient to have a > standard, well- and widely-known piece of software around. You may not > like it but both Sendmail and BIND are the de facto standards. Period. > > You have all hooks to throw them away and substitute them with something > different, so please don't bother the world if they don't grok your > personal taste. > > Not another sendmail-versus-whatever discussion please... Please! > > Helge > > P.S. Get rid of vi; cat should be enough for everyone! When did it become a sendmail-versus-whatever discussion? The question is simply this: why are there large, complex, non-BSD packages in src-contrib that are not critical to the running of many types of systems, and not strictly a dependency of the system proper? (Before you jump and say that some local mail delivery tool should be system-mandatory, note that the original suggestion was that if there is to be a default mail tool, it should be some very simple binmail style thing, not a whole full blown sendmail implementation.) I don't buy the argument that the software is there so that you can use it when you finally find a need for it. That could be said about much of the generally useful software that has found a home in the ports collection. Nor does the fact that sendmail and bind are de facto standards mean they should be afforded any different treatment than the many other de facto services that live in the ports tree. I'd guess that there are a similar number of BSD machines running apache as there are running sendmail, and probably substantially more than are running BIND -- but you don't find that piece of de facto web serving software in src-contrib, do you? The suggestion that moving sendmail or bind into the ports tree is tantamount to doing the same to vi is interesting, but I see a major difference between the two: I can hardly contrive an example where vi wouldn't be useful to have, whereas I have actually encountered many cases in my work where a DNS server and an MTA are both unwanted and even needed to be removed due to constraints unrelated to name resolution or mail transport. And, as Helge prematurely pointed out, there are perfectly functional alternatives to both of those packages, too. It seems analagous to opt-in (ports) versus opt-out (src) for software, except that the opt-out procedure is more involved (alter make.conf, buildworld) than the opt-in procedure (install the port), and is more difficult to manage (especially if you want to manage the software independent of the rest of the OS.) Given those characteristics, why would one prefer the "opt-out" method? Actually, when you start to think along those lines, it starts to take a Microsoft-esque bundled software favoritism shape, which might be why the "sendmail-versus-whatever" flag was raised prematurely. But I'm assuming that there are actual good reasons for this software being in the main tree, not simply for the advocacy of some particular software, as that seems pointless. (Also because the idea gives me the creeps.) My best guess for why they remain there is the momentum generated by their very presence -- if many or most people use that software, and moving it out would break their setups, it's not likely to change any time soon, eh? I've noticed that there are, in fact, sendmail and bind ports -- does anybody use them? if so, why, and do they interact poorly with their src-contrib counterparts? If not, why are they there? Is there some political struggle afoot to cleave these packages from the BSD sources proper? Are these old, deprecated ports? In fact, it seems like about 50% of the packages in src-contrib can also be found in the ports collection. That's pretty confusing, actually. Apparently, I have the bzip2 package installed for no reason, as it's part of stable. Pulled in as a logical dependency of tar's -y option, maybe? Are there plans to eventually deprecate the duplicated ports, or the packages in src-contrib, or neither? Is there any sort of rough policy on how to decide where to put a piece of non-BSD software? Anyway, I just wanted to say that some of Karsten's comments resonated with my own experiences, and while perhaps a little harshly worded, I think the questions deserve some thought. /Yeasah To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-stable" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?026501c1d561$90d61de0$0200a8c0>