Date: Wed, 27 Mar 2002 18:33:03 -0500 From: "Yeasah Pell" <yeasah@apocalypse.org> To: "Karsten W. Rohrbach" <karsten@rohrbach.de>, "Paul David Fardy" <pdfardy@mac.com> Cc: <stable@FreeBSD.ORG> Subject: base system vs. packages Message-ID: <059301c1d5e7$beec8da0$0200a8c0@gauss> References: <BDE5BE99-41CC-11D6-BCD2-0003938656E6@mac.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- Original Message ----- From: "Paul David Fardy" <pdfardy@mac.com> > Ultimately, it's not about tradition or heritage and it's not about > evolution, either. The real argument for keeping them runs like this: > Sendmail and BIND work. Sendmail and BIND remain in active development. > And, most importantly, each is actively maintained by FreeBSD committers. > > Pulling them out of contrib is not evolution, but revolution. You'll have > to convince freebsd-core that it's better for [who?] to maintain [what?] > than to continue letting Greg Shapiro--who's FreeBSD work may even been > supported by Sendmail, Inc. Greg's work, alone, is enough to keep it in > contrib. Greg ensures that "it ain't broke, so don't fix it." From this posting and others, I'm starting to get the impression that the real, underlying reason that sendmail and bind remain in src-contrib is that the maintainers are developing/maintaining at a rate that would make generating port patches and doing port versions prohibitively time consuming. I can definitely appreciate the strength of that argument. It would be possible (in principle) to have the ports system be able to pull source from a seperate FreeBSD src tree, instead of a distribution tarball and patches (maybe even directly from src-contrib). I wonder if there are other ports that are really pretty highly customized for FreeBSD that would work better as vendor branch CVS imports (like sendmail is, I presume). Has this been considered already? This could certainly help the ~50% packages in src-contrib that are duplicated in the ports tree, which I feel is a deplorable state of affairs. I guess that it would be appropriate to list what I feel are the advantages of moving these packages out of src-contrib: 1) It feels much more logical and consistent. This is roughly analagous in strength to the "tradition" or "heritage" argument for keeping them in src-contrib, so I figured I'd include it. 2) Security. The interests of system security dictates that you include as little as possible in a default system, and allow additional software to be added on *as needed*. 3) Management. I can pick a version, upgrade, downgrade, switch to a different but similar software package, and stop using the software altogether all without having to touch any other part of the system. 4) Insulation. People not using the software will not be affected by changes to the software, as recently happened with sendmail. 5) Cohesion. Some software lives in both src-contrib and ports (in fact about half of src-contrib, by my count). Having two sources for the same software has all sorts of problems. Bugs/security holes need to be fixed in two places. People get confused as to which software they are running, and under what circumstances. In extreme cases, both software packages could come into use in different contexts, and if they were divergent and incompatible versions... well, you get the point. (Some people have characterized this as adding "character" to the system, which boggles my mind.) The arguments that I've heard so far to keep them in src-contrib: 1) Tradition/heritage. It's part of BSD, and people expect it to be there. 2) They are in active FreeBSD-specific development (which isn't readily accomodated by the ports system as it stands) 3) We'd lose the contribution of Greg if sendmail was moved out of the core system. (Could this possibly be true?? I assume that Greg would eventually become involved in the discourse if it looked like something would actually happen, and his veto would definitely shut down the possibility of doing any of this. Some people are just That Important.) I'm sure I missed points on both sides. Comments? It also occurs to me that pro-port items 1, 2 and 4 could be at least partly accomplished with changes to the installer, as follows: * BIND, sendmail, and anything else in src that might fall on the other side of the razor are moved into a different distribution set for the installer, similar to the non-port XFree86. They could be selected by default -- the main idea is to allow a person to install FreeBSD from media without packages that aren't _logically_ part of the core system (heritage and tradition notwithstanding) * It'd definitely be nice if a skeleton make.conf was set up based on which distribution sets were selected during the install -- even if BIND and sendmail are never changed at all. This would mean somebody who installed a stripped down FreeBSD system wouldn't unexpectedly get all those packages when they started tracking a branch. Unfortunately, I don't know much about the installer or the generation of distribution sets, so I have no idea if that would be difficult or not. /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?059301c1d5e7$beec8da0$0200a8c0>