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:
pgpDYl1lsiUnE.pgp
Description: PGP signature