From owner-freebsd-hackers Tue Aug 27 05:13:36 1996 Return-Path: owner-hackers Received: (from root@localhost) by freefall.freebsd.org (8.7.5/8.7.3) id FAA02264 for hackers-outgoing; Tue, 27 Aug 1996 05:13:36 -0700 (PDT) Received: from eel.dataplex.net ([208.2.87.2]) by freefall.freebsd.org (8.7.5/8.7.3) with SMTP id FAA02255 for ; Tue, 27 Aug 1996 05:13:33 -0700 (PDT) Received: from [208.2.87.4] (cod [208.2.87.4]) by eel.dataplex.net (8.6.11/8.6.9) with SMTP id GAA02262; Tue, 27 Aug 1996 06:52:03 -0500 X-Sender: rkw@shark.dataplex.net Message-Id: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Date: Tue, 27 Aug 1996 06:52:09 -0500 To: Paul Richards From: rkw@shark.dataplex.net (Richard Wackerbarth) Subject: Re: Am I wrong or is this just stupid?r Cc: hackers@FreeBSD.org Sender: owner-hackers@FreeBSD.org X-Loop: FreeBSD.org Precedence: bulk Paul Richards replies: >rkw@dataplex.net (Richard Wackerbarth) writes: >> We would probably want to have 3 conditions. >> 1) Unconditionally build the tools >> 2) Test to see if the tools are up-to-date >> 3) Assume the tools are up-to-date as of the time of the cookie. >> This can be done with two tokens, "tools_built" and "tools_changed". > >This is all ridiculously complex for a relatively rare occurence these >days. > >An upgrade of the tools does *NOT* imply that a bootstrap >stage is required. We're talking about different problems here. I >think an explanation of the historical reasons for the current setup >is required for those who weren't around. I tend to agree. However, there are those who persist in the notion that they "must" have the bootstrap phase AUTOMATICALLY included. Setting up the mechanism is not all that difficult and it does allow us to "keep the troops happy". The biggest problem that I have with doing ANYTHING to the "make" structure is that there is no concensus building. Anyone who proposes a change is immediately "shot down" by someone who refuses to allow progress if it means that he has to CHANGE anything about his favorite mode of operation. There are certainly arguments as to why each of the three above mentioned targets are of value. Exclusive use of (3) leads to missed changes to things like "config". In the typical case, (2) is more time consuming than necessary. Case (1) COULD be handled by manual bootstrapping, but that is "too hard" for some HA's. It appears to me that many of the "hackers" have never worked on a large shared system or with cross compilers. When you have your own private space and are only making minor changes to a single native implementation, you can get away with "shortcuts" that don't work in the general case. It IS a little harder to set things up to handle the general case, but once it is done, it is NOT more difficult to use. However, before any real progress can be made, people need to break out of the mentality trap what prohibits change.