Re: Outdated GNU config (config.{sub,guess}) and autotools-dev
On Sun, 22 Jul 2001, Marcus Brinkmann wrote:
>>>> Can be worked around: the more complicated script I suggest will tag the
>>>> changelog properly. That information is NOT lost, as it makes to the
>>>> .changes file, which is sent to the proper @list.debian.org ML, even if the
>>>> autobuilder is not doing a source NMU.
>>> Again, does only work if the files stay fixed atfer the source is
>>> generated.
>> No. This *always* work; One cannot upload something to debian without
>> leaving tracks in the form of a .changes file, which should be ALWAYS
>> archived (if it is not, we have something wrong...). If one adds
>> autotools-dev support that leaves no track on the changelog, it is his
>> fault, not autotools-dev's.
> The autobuilders are not supposed to make changes to the source, including
> the changelog. I didn't mean work in a technical way, more in a policy
> compliant way (incl the license issue).
However, I think a makefile rule that allows the source code to be
self-modifying by grabbing newer copies of config.{guess,sub} poses a problem,
if the changes are also reverted as part of the build process in the 'clean'
rule. I don't particularly want to be carrying around the entire text of
config.* in my Debian diff.gz, and I don't see this as necessary if you have a
Makefile that provides a proper recipe for reproducing this feat. We don't
know what version of libc headers the package will be built against, nor is
a trail of this left in the final binary package; if we have a patch that
causes 'autoconf' to be invoked at build-time to incorporate changes to
configure.in, we don't know what version of autoconf will be used.
Not knowing the exact version of config.sub and config.guess that was used on
the autobuilder doesn't bother me, therefore, as long as it's newer than or as
new as the version provided in the package. I'd rather have to worry about
incompatible interfaces to these scripts once a decade, than worrying about
new Linux ports once every 6 months.[0] :)
> However, I don't think it is a good idea to rush over these details
> and diminish them. Changing the source at binary build time and
> changing the Debian changelog at binary build time are both
> suspicious things to do, and a careful inspection if there is a real need
> and what other solutions there are, and how existing policies can be met,
> is important, even if the actual effect of those operations is likely to
> be small (after all, the quantity of a violation does not matter, and
> it also sets a precedent).
Note that the configure script itself is used by the autobuilders to make
'automatic changes to the source' (generated header files), and that these
changes are far more significant, and this aspect of the build environment is
far more difficult to reconstruct precisely, than anything concerning
config.{guess,sub}.
If I build a binary package against a version of glibc that provides 64-bit
file support, and don't build-depend specifically on a version of libc6-dev
that has 64-bit support, does this constitute a GPL violation? If not, why
do config.{sub,guess}, whose versions have almost no bearing on the resulting
binary package, represent a problem? The package either builds or it
doesn't, and if you have a version of config.sub new enough to allow the
package to build, the particular version of config.sub you have will have zero
impact on how the source is compiled.
Moreover, the package author can't claim copyright on config.sub and
config.guess -- these scripts may /ship/ with the various packages, but
they're not a part of the software being built. If automatically replacing
config.guess and config.sub is a violation of the GPL, who is the injured
party? Is it the FSF's copyright on this code that would apply?
Steve Langasek
postmodern programmer
[0] This is not to say that packages don't need attention for other reasons,
but I would be quite pleased if autoconf support were fire-and-forget with
respect to new architecture *names*.
Reply to: