Date: Sat, 17 Feb 2001 09:26:57 -0500 (EST) From: Robert Watson <rwatson@FreeBSD.ORG> To: Matt Dillon <dillon@earth.backplane.com> Cc: Mark Murray <mark@grondar.za>, Jordan Hubbard <jkh@winston.osd.bsdi.com>, arch@FreeBSD.ORG Subject: Re: Moving Things [was Re: List of things to move from main tree] Message-ID: <Pine.NEB.3.96L.1010217091721.56503L-100000@fledge.watson.org> In-Reply-To: <200102170742.f1H7ggP20563@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, 16 Feb 2001, Matt Dillon wrote: > :We currently split the OS into two classes; src and ports. For a long > :time now I have had an idea for more of a continuum, and less of a > :dividing line. > : > :Basically it is this: > : > :The src and ports remain, but get redefined in a rather extreme way: > > I don't think this is possible. One of the biggest differences between > src and ports is that src is audited to a much higher degree then > ports. Ports is virtually unaudited. There is no continuum to speak > of and I see no continuum on the horizon. > > Shoot, and I said the last posting was my last word. Ok, THIS posting > is my last word! Well, I think the problem is that everyone sees src and ports in a particular light, whereas there are a number of accesses to compare them on that are relevant. I'll list a few that I think are interesting, but part of this is a response to Jordan's comment and a suggestion that if the "src" and "ports" groupings of features are somewhat arbitrary and can always be moved around: o With src/, you get complete revision control of your modifications and the base code in question, including a fair amount of magic in the form of vendor branches for remerging local changes. o Complete source revision gives you a high level of reproduceability for a release, or for binary updates (a service that we'd like to be able to provide). o With src/ you get integration of the source in the tree allowing you to build the complete system based purely on CVS checkouts and updates, meaning that you don't rely on online source distribution during building, and are not vulnerable to the infamous checksum change o With src/, there's are coordinated attempts to address the source upgrade issue, and documentation of the upgrade issues, well as an attempt to provide documentation and tools for improving configuration updates o We expect that all src/ developers be in touch with the developer community and get approval for large changes in source code, and increasingly, auditing of that code. o We expect a higher level of security awareness in src/ code, and the security-officer is expected to provide a higher level of support for src/ o With the ports/ tree, it's easier to allow third parties to maintain their build compatibility changes without being tightly integrated into the FreeBSD developer community o With ports/, it's easier to allow users to customize the build options for software when they install it o With ports/, it's easier to make modular binary install chunks o With ports/, it's easier to represent build and install dependencies between arbitrary components o It's easier to imagine a *BSD communal ports/packages collection than a single *BSD src/ tree with ifdefs. An observation that Jordan and others have made is that you can distinguish source structure and install-time modularity issues, meaning that it's possible to imagine having the tight integration of sendmail and bind into the source tree, and related local patches and reproduceable source integration / auditing, while maintaing packages-like install-time choices and bundling. A lot of the reasons that people argue for removing code from the tree relate to the desire for high install-time modularity, and a lot of the reasons people argue for inclusion in the source tree are tight source integration, reproduceability, and configuration merging and management. We can have both you know. :-) Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1010217091721.56503L-100000>