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

Re: [RFC] GNU autoconf and dpkg-architecture

Hi Henrique,

On Fri, Feb 01, 2002 at 12:09:15PM -0200, Henrique de Moraes Holschuh wrote:

> Debian policy states:
> (2.4.3):
>      [...]
>      You should make sure that the `configure' utility detects the correct
>      architecture specification string (refer to Section 12.1,
>      `Architecture specification strings' for details).
>      [...]

There appears to be a disconnect between autoconf and Debian on this,
though.  The autoconf docs say (about specifying the system type):

    TYPE can either be a short name for the system
    type, such as `sun4', or a canonical name which has the form:


    where SYSTEM can have one of these forms:


whereas Debian policy section 12.1 says:

    Note that we don't want to use arch-debian-linux to apply to the
    rule architecture-vendor-os since this would make our programs
    incompatible with other Linux distributions. We also don't use
    something like arch-unknown-linux, since the unknown does not look
    very good.

I'm guessing that we get away with just "i386-linux" because the
"config.sub" script canonicalizes it for us.  Indeed, that script also
eschews "COMPANY=unknown" because 'the word "unknown" tends to confuse
beginning users'; for "i386-linux", we end up with "i386-pc-linux-gnu".

I wonder whether older versions of "config.sub" will choke on

> By using something like this (GNU make makefile fragment):
> export DEB_HOST_GNU_TYPE  ?= $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE)
> export DEB_BUILD_GNU_TYPE ?= $(shell dpkg-architecture -qDEB_BUILD_GNU_TYPE)
> 	./configure --build=$(DEB_BUILD_GNU_TYPE) --host=$(DEB_HOST_GNU_TYPE) \
>                     --prefix=/usr ...
> Instead of simply letting configure run config.guess and config.sub to find
> out the architecture, one gets a few benefits.

Note that supplying these will only suppress running "config.guess".
The "config.sub" script is run unconditionally, to canonicalize the
build and host values.

> 1. The build and host architecture are correctly set to the ones Debian
>    should be using (e.g. i386-pc-linux-gnu for all ia32 machines).

True, this ensures that all debian builds use, e.g. "i386" rather than

> 2. config.guess is never called (a damn Good Thing)
>    Less wasted CPU cycles, and one less point of failure are a Good Thing!

The fraction of CPU cycles used for "config.guess" in a typical
build is surely negligible!

Having one fewer points of failure is a reasonable point.

> 3. It looks like the Right Way to do things re. the
>    almost-never-used-for-anything build and host stuff in GNU config,
>    and the spirit of section 5.2 and 12.1 of Debian policy.

That's not a technical argument!  :-)

Steve Langasek's point about paving the way for cross building is
a reasonable point.

> The question is:
> Should I try to get the above way of calling configure to be the "do it
> unless you know damn well you need to do it differently" way of doing things
> in all Debian packages that use GNU autoconf?  

Sending email to d-d-announce is a fine idea.  [I personally think
that more of these "best practices" announcements would be welcomed.
For example, an announcement about the fact that packages.debian.org
understands URLs in package descriptions would be a boon.]

What do you want as the end result?  A policy change?  I don't
anticipate any harm in doing it your way, but I don't see a huge
benefit, either.  Sending mass bug reports or changing policy to force
the use of --build doesn't seem justified to me.

The main benefit that I see is #2: avoiding build failures on
relatively new machine architectures.  However, this applies only to
the relatively few packages that actually *use* the "host" value.  For
most packages, the change is only busy-work, and you risk breaking
something due to a typo.

Perhaps an effective way to deal with this (in addition to an email to
announce) is to train the buildd maintainers to point to your text
when they send a bug report on a package that failed to build because
of an old config.guess.


by Rocket to the Moon,
by Airplane to the Rocket,
by Taxi to the Airport,
by Frontdoor to the Taxi,
by throwing back the blanket and laying down the legs ...
- They Might Be Giants

Reply to: