the RELEASE (which takes care of having one common version, with known
MD5 cksums). The patchkits would contain only the whole files, not diffs.
The patch installer would have to examine the target files before doing
anything, and if the MD5 checksums (relative to the last patchkit) don't
The RCS info stored in the binaries is insufficient for this purpose. There is
no record of the versions of all included files. Changes to constants and/or
macros would not be identifiable.
Jim Bloom
[EMAIL PROTECTED]
Kris Kennaway wrote:
>
> On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
>
On Tue, 25 Apr 2000, Kris Kennaway wrote:
>You've never run ident(1), right? :)
Very cool! No I hadn't. I was working with the assumption that it was
probably possible, but I know very little about how RCS actually works.
I just know that it does work and that's always been enough for me to
us
On Tue, 25 Apr 2000, Brandon D. Valentine wrote:
> 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 fr
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 -re
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 wo
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
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> 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?
If you are using someone's patches, you must be patching the files that they
provided. If yo
< said:
> I love binary answers :-) Which brings me to my original point: it looks
> like you can only do binary patches relative to a -release. Unless
> you want to blindly patch and hope for the best. Rather unlikely.
I think you are right. Doing so would still require resolving the
full depe
On Tue, Apr 25, 2000 at 02:50:46PM -0400, Garrett Wollman wrote:
> < said:
>
> > 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?
>
> No.
I love binary answers :-) Which brings me
< said:
> 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?
No.
-GAWollman
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the messa
On Tue, Apr 25, 2000 at 01:00:28PM -0500, Richard Wackerbarth wrote:
> On Tue, 25 Apr 2000, Wilko Bulte wrote:
>
> > > On a similar note: I think one of serious drawbacks of FreeBSD's model
> > > for updating and bugfixing the stable branch is 'make world'. It's very
> > > inefficient and cumbers
On Tue, 25 Apr 2000, Wilko Bulte wrote:
> > On a similar note: I think one of serious drawbacks of FreeBSD's model
> > for updating and bugfixing the stable branch is 'make world'. It's very
> > inefficient and cumbersome way to do this on production machines. STABLE
> > is stable enough for us t
13 matches
Mail list logo
