From owner-freebsd-current Tue Apr 25 13:15:15 2000 Delivered-To: freebsd-current@freebsd.org Received: from mail.ddg.com (eunuch.ddg.com [216.30.58.66]) by hub.freebsd.org (Postfix) with ESMTP id BC08D37BED5; Tue, 25 Apr 2000 13:15:11 -0700 (PDT) (envelope-from rkw@dataplex.net) Received: from nomad.dataplex.net (24.28.73.209) by mail.ddg.com with SMTP (Eudora Internet Mail Server 2.1); Tue, 25 Apr 2000 15:15:04 -0500 From: Richard Wackerbarth To: kris@FreeBSD.org Subject: Re: Patchkits Date: Tue, 25 Apr 2000 15:15:03 -0500 X-Mailer: KMail [version 1.1.41] Content-Type: text/plain Cc: freebsd-current@FreeBSD.org References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00042515150301.02802@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG On Tue, 25 Apr 2000, Kris Kennaway wrote: > On Tue, 25 Apr 2000, Wilko Bulte wrote: > > OK. But you do have to uniquely identify the binary that needs to be > > patched. So, my question is when you generate 10x the same binary, will > > all these 10 binaries have the same MD5 checksum? In other words: if > > people did a local buildworld once on a -release sourcetree will all the > > executables have the same MD5 as the ones on the -release cdrom? > > I don't think a binary patch is workable: all it takes is a single local > buildworld and you've got an unpatchable system. Furthermore, I'd > speculate that binary patches would usually be on the same order of size > as the file itself. What *would* work is including the entire new file in > the package. This is what solaris does. > > However, there are serious regression-testing and dependency problems with > a scheme like this - i.e. making sure you've included *all* of the > relevant changes. Sounds like a package manager from another OS. :-) To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message