From owner-freebsd-hackers Tue Apr 4 21:23:09 1995 Return-Path: hackers-owner Received: (from majordom@localhost) by freefall.cdrom.com (8.6.10/8.6.6) id VAA02257 for hackers-outgoing; Tue, 4 Apr 1995 21:23:09 -0700 Received: from trout.sri.MT.net (trout.sri.MT.net [204.182.243.12]) by freefall.cdrom.com (8.6.10/8.6.6) with ESMTP id VAA02250 for ; Tue, 4 Apr 1995 21:23:05 -0700 Received: (from nate@localhost) by trout.sri.MT.net (8.6.9/8.6.9) id WAA09399; Tue, 4 Apr 1995 22:26:47 -0600 Date: Tue, 4 Apr 1995 22:26:47 -0600 Message-Id: <199504050426.WAA09399@trout.sri.MT.net> To: "Rodney W. Grimes" Cc: julian@tfs.com (Julian Elischer), freebsd-hackers@FreeBSD.org Subject: Re: new install(1) utility In-Reply-To: <199504050306.UAA09498@gndrsh.aac.dev.com> References: <199504050306.UAA09498@gndrsh.aac.dev.com> Reply-To: nate@sneezy.sri.com (Nate Williams) From: nate@sneezy.sri.com (Nate Williams) Sender: hackers-owner@FreeBSD.org Precedence: bulk > Hey, two more people in agreement. Or at least partly. I am not > so sure about having install do the cmp, I think that part is best > left externally. My reasoning here is that if the cmp is inside > install we will exec both install and cmp no mater what, if we do a > cmp || install > it would be possible to save the exec of install if the cmp > successeds. I think Poul's ideas of using his memmap/memcmp is the way to go, and I think that's what Steven is doing. This is a much bigger win than even the regular cmp program (faster since it's very specific), and it does save us from doing the actual install. > Using cksum is *not* the way to go, we already have Pouls benchmarks > of cmp vs cksum on this, and cksum is not fail safe, it is possible > for 2 files to have the same checksum but contain different data, > very unlikely, but possible. I would have to see it to believe it. And, I don't remember any of Poul's benchmarks that you are speaking of just that he said his memmap/memcmp stuff for CTM was faster than cksums. > I do see the need to have install have the -t option to copy time > stamps. We are still going to have problems because libraries are going to be newer even if we save the timestamps. If I delete the library I used during installation, any library I build will have a different timestamp than the one I'm comparing against. > Bruce, would this mean we could drop the ranlib after installing > libraries? The ranlib option after install is a moot point IFF we no longer install the libraries if they are the same. Really, I'm going to quit following up after this. :( Nate