[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Architecture independent binaries and building from source

This one time, at band camp, sean finney said:
> just to add my $0.02,
> On Tue, Aug 10, 2004 at 08:58:37AM -0700, Shaun Jackman wrote:
> > debsums does not exist on non-Debian systems. md5sum can quickly and
> > easily show that my BSD system and my Debian system are running the
> > same version of a Java library if both are distributed with upstream's
> > architecture independent binary.
> i don't think that qualifies as a good reason.  as the package
> maintainer, part of your responsibilities is to ensure that
> the program is correctly versioned and builds apropriately.  as
> a user, when i want to verify a program's version, i don't md5sum it
> with what i downloaded from upstream's website.  i dpkg -l foo, or
> maybe even program --version.

Agreed, there.

> > As a rule, we don't regenerate all files from source. We don't
> > generally, for example, regenerate configure (using autoconf) from
> 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.

> > configure.ac even though it is possible. No one can sensibly suggest
> > that a shell script of twenty thousand lines is in source form. I
> i've yet to see a configure script that's 20000 lines long

steve@gashuffer:~/Debian/clamav/0.75.1/clamav-0.75.1$ wc -l configure
14533 configure

Not 20,000, but within an order of magnitude.

> On Tue, Aug 10, 2004 at 09:13:56AM -0700, Shaun Jackman wrote:
> > The text is clear that both the source code and the binary are
> > required. I have included both in the package.
> 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.  

> > I certainly agree that debian/rules must rebuild the binary packages
> > from the sources packages (FTBFS is definitely a bug). However, I
> > don't agree that all files must be indiscriminately rebuilt from their
> > base source. This is not current practice in any case. We do not, for
> > example, generally rebuild configure from configure.ac.
> can you give an example where we do this for a *binary* file?  i don't
> see the same correlation that you do.  there are cases where we do
> ship arch-indep binary files (.ogg sounds, for example), but i see
> this as a far different situation since it's quite clear that your
> bytecode was clearly generated from a preferred form of sourcecode at
> one point.

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.

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.  

> i can certainly name a good number of cases where this does seem to
> be a precedent, like with scheme and python modules.

That doesn't mean they're all sensible.  ISTR a debate about python, at
least, and the compiling of modules at install time.  Again, I am not
fluent in java (or particularly python), so I may be wrong on technical
issues, and am perfectly willing to be corrected.  The principle, I
think, is sound though.  If there is a technical reason why upstream's
pre-compiled binary is no good for Debian (different toolchain, problems
introduced by missing symbols or something (does java even have symbols
in the C way?)), then I say rebuild it at build time.  If not, then it
seems that this is making a mountain out of a molehill.

My 2p.
|   ,''`.					     Stephen Gran |
|  : :' :					 sgran@debian.org |
|  `. `'			Debian user, admin, and developer |
|    `-					    http://www.debian.org |

Attachment: pgpCZ6xToABpr.pgp
Description: PGP signature

Reply to: