On Tue, Aug 10, 2004 at 02:14:27PM -0400, Stephen Gran wrote: > > first, the configure script is not a binary file, the bytecode you > > discuss is. second, while it can be generated from the configure.ac, > > it's questionable whether or not the configure.ac is the > > "preferred form" for modification. > > Of course it is - do you manually edit configure, or do you edit > configure.ac, aclocal.m4, acinclude.m4, etc.? I know which one I do. okay, i withdraw my statements about configure/autoconf... i wasn't thinking too clearly obviously (yes, i didn't have my coffee this morning). > > but there's no guarantee that the source code can successfully build > > the binaries included if it wasn't used to build the binaries included > > in the first place. > > If it doesn't, that would be a bug. yeah, and my point is that there's no way of reliably verifying this other than relying on upstream and/or the package maintainer's word. > I ship binary files in clamav-freshclam, and the package clamav-data > also ships the same files. These are hex-code files used to store the > signatures used by clamav for matching. I could dump all the signatures > out to text, and then rebuild the cvd's at build time, but that just > seems absolutely silly to me. I am sure there are other examples of the > same kind of thing, but I haven't looked. it's an interseting argument, and leads to what you bring up: > I don't particularly know java, but if it's a pre-byte-compiled binary > that is really arch-independant, then I don't really see the need to > force the rebuild of the binary at debian/rules build time. I also > don't see the need to rebuild manpages that are originally included as > sgml/xml/whatever at build-time either, or turn one image format into > another, or any of these kind of things, but maybe that's just me. > Doing the build once ahead of time for arch-independant stuff seems > like a huge gain in overhead. so somewhere, someone has to draw the line about what qualifies as binaries needing source and what qualifies as distributable forms of binary data. i don't know enough about clamav to form an argument one way or another, but in the case of the java bytecode (i'm guessing it's either a program or libraries), it seems more clear. plus, the reasoning for doing it in the first place isn't all that great. i guess my thinking is: if it were a binary blob in an arch-dependant package, would it still be acceptable? i seem to think a reference file like you've mentioned would still be lumped in the okay pile, but a program/library would be kicked out. On Tue, Aug 10, 2004 at 08:25:56PM +0100, Roger Leigh wrote: > > but there's no guarantee that the source code can successfully build > > the binaries included if it wasn't used to build the binaries included > > in the first place. > > Agreed. There's also no absolute guarantee that the compiled binaries > match the distributed source; perhaps they are outdated or required > some additional tools to build? and what if those tools were non-free? sean --
Attachment:
signature.asc
Description: Digital signature