[prev in list] [next in list] [prev in thread] [next in thread]
List: debian-devel
Subject: Re: Architecture independent binaries and building from source
From: sean finney <seanius () seanius ! net>
Date: 2004-08-10 22:32:09
Message-ID: 20040810223209.GA10654 () seanius ! net
[Download RAW message or body]
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
--
["signature.asc" (application/pgp-signature)]
--
To UNSUBSCRIBE, email to debian-devel-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic