Re: Architecture independent binaries and building from source
On Tue August 10, 2004 10h29, sean finney wrote:
> 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.
dpkg is only available on Debian. Since this is a library,
`program --version' isn't possible. If possible, I believe it is an
advantage to redistribute a binary that is identical to upstream's
distribution. I believe this is as much applicable to source packages
(which we go to efforts to distribute unmodified) as it is to
binaries, so long as there is no technical reason to modify that
binary.
> > 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.
I disagree. I would only modify a configure script as a last resort.
configure.ac is the preferred form for modification.
> > 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, though there
> do exist shell scripts of comparable length that are in their "source"
> form. here's a few i happen to have laying in /usr/bin on my machines:
>
> 2058 texconfig
> 2327 abcde
> 4419 groffer
$ wc id3lib3.8.3-3.8.3/configure
24465 89530 780723 id3lib3.8.3-3.8.3/configure
> 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.
Quoting Stephen Gran:
> 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 think the distinction between a binary and a text file is largely
immaterial. The important distinction is a file in the preferred form
for modification and a file in a derivative form. We redistribute many
files in derivative form from upstream without modification. I intend
to do the same here.
> i can certainly name a good number of cases where this does seem to
> be a precedent, like with scheme and python modules.
Precedent is a useful reference. I don't, however, take it as canon.
Cheers,
Shaun
Reply to: