From owner-freebsd-current Wed Feb 22 16:37:33 1995 Return-Path: current-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.9/8.6.6) id QAA12215 for current-outgoing; Wed, 22 Feb 1995 16:37:33 -0800 Received: from localhost (localhost [127.0.0.1]) by freefall.cdrom.com (8.6.9/8.6.6) with SMTP id QAA12206; Wed, 22 Feb 1995 16:37:31 -0800 X-Authentication-Warning: freefall.cdrom.com: Host localhost didn't use HELO protocol To: Nate Williams cc: Poul-Henning Kamp , wollman@halloran-eldar.lcs.mit.edu, current@freefall.cdrom.com Subject: Re: TRUE and FALSE In-reply-to: Your message of "Wed, 22 Feb 95 16:45:52 MST." <199502222345.QAA15987@trout.sri.MT.net> Date: Wed, 22 Feb 1995 16:37:30 -0800 Message-ID: <12205.793499850@freefall.cdrom.com> From: "Jordan K. Hubbard" Sender: current-owner@FreeBSD.org Precedence: bulk > At what gain are we doing this? I believe it's a noble gain to have the > source tree compile w/out reference to /usr/include, but what does it > gain us? The only thing I can see where it's a big deal is building a Oh geeze! I can't believe we need to explain *that*! Look, right now we have an intolerable situation where we have this mutant world target from hell that requires updating each and every time some weird bogon in the tree requires that it be updated in a specific sequence before anything else will work. It's already tripled in size since we first created it and it's not at all inconceivable that (if things keep going this way) the world target will be 3 pages long by the time 2.2 comes out! That or we'll finally run into a case we can't solve with one pass and we'll end up with multiple sub-makes from the darkest reaches of Hades! That and the simple fact that depending on includes and libraries from outside of /usr/src is incredibly *error prone*. If you and Garrett feel so strongly about this, then I have a suggestion: YOU BE THE RELEASE ENGINEERS FOR 2.1! Otherwise, and with all due respect, kindly put a plug in it.. It is incredibly irksome to be one of the ones bitten by this and then be corrected by the two people here who have NEVER done a release and have always run rapidly in the other direction every time the hat was passed around for a volunteer to actually do this grueling task! Do you know that the 950210-SNAP release has a bogus ps and several other binaries for which the fixes are in /usr/src? How did that happen, you ask? Well, I made the release on time and time had slightly older contents of /usr/lib. Since I was technically making and installing into a sub-tree it didn't occur to me that the various utilities would link themselves with the includes and libraries in /usr rather than in ${DESTDIR}/usr, and I got binaries that were out of sync with the actual sources. Now you can argue that I should have gone through the arduous process of doing a make world first, or perhaps a make install then a chroot then another make all and ... but I didn't have a full 24 hours to tie up my machine with this at the time, so I took what looked like a reasonably short cut and it bit my ass. This should NOT HAVE HAPPENED and if we had a properly designed source tree it WOULD NOT HAVE. Now Poul-Henning is proposing a final solution to this mess and you guys, who have never done a release and have very little grasp of the issues involved (and I won't be convinced otherwise until you guys have actually DONE a release and have truly walked the steps), are picking it to death on the basis of having to type TWO INCREDIBLY SIMPLE COMMANDS for what is also an exceptional case - hacking on kernel dependent sources that aren't in /usr/src. Excuse me while I go scream into a pillow or something. Jordan