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?

Any place I have used the pronoun 'you' below is a reference to Andrzej
Bialecki, originator of the thread, and not Wilko Bulte, who happened to
provide a nice starting point for my response.

Ideally, yes.  But this assumes that the binaries are built on the same
architecture with the same compiler options(especially optimizations).
If you feed it the same asm as86 should always generate the same binary.
Of course the minute you change compiler versions or add a different
-march or -O flag to gcc you run the risk of ending up with slightly
different binary code.  To do this using checksums would be problematic.
The only way something like this is feasible is if the binaries
themselves contain information about what version they are.  In other
words some sort of a header in the binary which contains the RCS version
number the binary was compiled from so that whatever method you were
using to sync your "binary" trees(no pun intended) so to speak can
compare RCS tags just as you would do with source.  If you were to
implement this you'd probably check the binary versions against
the remote repository and then any outdated binaries would have a
replacement downloaded into /usr/upgrade or some such directory where
one could later chdir and run a Makefile from single user mode to move
those new binaries into place.  Since there are already servers which
generate nightly binary snapshots the problem of keeping a -STABLE
binary set available is already solved.  If you want to do this you need
to come up with a cvsup patchset to support this and a proposal for how
to keep RCS tags available in the binary header without breaking
compatibility.  You also need to believe strongly in the necessity of
such a system and you need to convince the project that it is important
and will not place a further strain on the project's resources.  Ideally
a system like this could be used to replace the current upgrade knob in
sysinstall.  I just don't know that this is as pressing an issue at the
moment as some of the other projects going on in the source tree so if
it is going to happen someone(namely you) is going to need to volunteer.

Brandon D. Valentine
[EMAIL PROTECTED]                         Illegitimi non carborundum.

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to