Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
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 to be able to prepare binary patches, which can be applied to a system in some (known) version. Question: are MD5 checksums the same for each and every build (assuming static sources obviously) or is there some timestamp (or something like that) in the generated binary. If there is, one could only create binary patches relative to a -release. Here your logic is wrong. When I make a binary patch, I don't HAVE to update anything that is not substantively changed. Think "make all" rather than "make world". From there, it is easy enough to generate a chain of patches just like CTM does for the sources. However, is it worth the effort? I don't know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
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 cumbersome way to do this on production machines. STABLE is stable enough for us to be able to prepare binary patches, which can be applied to a system in some (known) version. Question: are MD5 checksums the same for each and every build (assuming static sources obviously) or is there some timestamp (or something like that) in the generated binary. If there is, one could only create binary patches relative to a -release. Here your logic is wrong. When I make a binary patch, I don't HAVE to update anything that is not substantively changed. Think "make all" rather than 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? "make world". From there, it is easy enough to generate a chain of patches just like CTM does for the sources. However, is it worth the effort? I don't know. I assume it is worth it to some end-users. The question is if the project can find someone to do it ;) -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000 20:16:00 +0200, Wilko Bulte [EMAIL PROTECTED] 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 message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
On Tue, Apr 25, 2000 at 02:50:46PM -0400, Garrett Wollman wrote: On Tue, 25 Apr 2000 20:16:00 +0200, Wilko Bulte [EMAIL PROTECTED] 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 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. -- Wilko Bulte Powered by FreeBSD http://www.freebsd.org http://www.tcja.nl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
On Tue, 25 Apr 2000 21:00:17 +0200, Wilko Bulte [EMAIL PROTECTED] 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 dependency graph, so that programs affected by a library change could all be identified. -GAWollman -- Garrett A. Wollman | O Siem / We are all family / O Siem / We're all the same [EMAIL PROTECTED] | O Siem / The fires of freedom Opinions not those of| Dance in the burning flame MIT, LCS, CRS, or NSA| - Susan Aglukark and Chad Irschick To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object module compatibility
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 you have created your own "imposters", you cannot expect to patch them. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
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. Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits
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 [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
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
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
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 from so that whatever method you were You've never run ident(1), right? :) Kris In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
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 use it. Thanks for pointing that out. If Mr. Bialecki is still interested in doing this, his job just got easier than I anticipated. =) 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
Re: Patchkits: Was :Re: SMP changes and breaking kld object modulecompatibility
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: 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 You've never run ident(1), right? :) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
