Your message dated 07 May 1999 13:27:10 -0500
with message-id <[EMAIL PROTECTED]>
and subject line [Debian Installer <[EMAIL PROTECTED]>]
packaging-manual_2.5.1.0_i386.changes INSTALLED
has caused the attached bug report to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what I'm
talking about this indicates a serious mail system misconfiguration
somewhere. Please contact me immediately.)
Ian Jackson
(administrator, Debian bugs database)
Received: (at submit) by bugs.debian.org; 15 Jan 1999 19:33:59 +0000
Received: (qmail 4603 invoked from network); 15 Jan 1999 19:33:58 -0000
Received: from sunu450.rz.ruhr-uni-bochum.de (134.147.222.33)
by master.debian.org with SMTP; 15 Jan 1999 19:33:58 -0000
Received: (qmail 27066 invoked from network); 15 Jan 1999 19:33:52 -0000
Received: from dialppp-5-173.rz.ruhr-uni-bochum.de (HELO localhost) ([EMAIL
PROTECTED])
by mailhost.rz.ruhr-uni-bochum.de with SMTP; 15 Jan 1999 19:33:52 -0000
Received: from brinkmds by localhost with local (Exim 2.05 #1 (Debian))
id 101F0S-0001M3-00; Fri, 15 Jan 1999 20:34:08 +0100
Message-ID: <[EMAIL PROTECTED]>
Date: Fri, 15 Jan 1999 20:34:08 +0100
From: Marcus Brinkmann <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Cc: Santiago Vila Doncel <[EMAIL PROTECTED]>,
Gordon Matzigkeit <[EMAIL PROTECTED]>
Subject: [PROPOSED] Adding dpkg-architecture to Packaging Manual
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 0.93i
Sender: Marcus Brinkmann <[EMAIL PROTECTED]>
Organization: Marcus Brinkmann's Home
Package: debian-policy
Version: current
Severity: wishlist
Hello,
to support the Hurd, and to make it possible to support cross compilation, I
propose the following changes to the Packaging Manual. I attach a set of
diff files against some package building scripts and a new script
`dpkg-architecture', too. They are probably not part of the proposal, but
provide an exemplary reference implementation for the suggested changes.
I set a discussion time of two weeks, according to the recommendation in
"A mechanism for updating Debian Policy documents" by Manoj. This should be
enough to sort out the rough edges and to correct my english.
But nothing will happen if I don't get two seconders. I therefore ask you to
second my proposal if you support it. I have CC'ed two persons who probably
want consider to second my proposal.
Thank you,
Marcus
===========================================================================
GOAL
The goal of the proposed changes is to add a facility to support other
operating systems beside Linux, and to allow support for cross compilation,
in the Debian package building scripts, including the individual
debian/rules files.
Two main issues are addressed:
* Getting the exact architecture specification string (until now only the
cpu could be queried, the OS was linux by default).
* Seperating the build architecture and the host architecture.
HOW IT WAS AND HOW IT WILL BE
Dpkg provided rudimentary architecture query facilities, which are not
sufficient to addresse above issues. It was suggested by Manoj and generally
considered a good idea to provide a new script instead adding further
options to already feature-blown dpkg. This script was then called by me
"dpkg-architecture" and is the central point of this proposal.
dpkg-architecture can be used to autodetect and set environment/make
variables which contain the needed architecture information. This proposal
includes changes to the Packaging Manual, which replace the instructions to
use `dpkg' to query the architecture with instructions to use
dpkg-architecture.
Also, cross compilation support is now actively encouraged. To make it clear
that this should only be provided if useful, I added some restrictions for
bug report submitters. I can imagine that some people want this paragraph to
be rewritten, and I am open to suggestions. The actual wording is the
maximum of restrictions I would find reasonable. However, if you think the
Packaging Manual should not mention bug reports at all, I would be happy to
remove the last sentence of proposed section 3.2.1.
--- packaging.text.old Fri Jan 15 18:04:16 1999
+++ packaging.text Fri Jan 15 18:38:26 1999
@@ -528,6 +528,12 @@
changelog, `debian/changelog' by default, and prints a control-file
format representation of the information in it to standard output.
+3.1.8. dpkg-architecture - information about the build and host system
+----------------------------------------------------------------------
+
+ This program is used either manually or internally by dpkg-buildpackage
+ to set environment variables which specify the build and host
+ architecture for the package building process.
3.2. The Debianised source tree
-------------------------------
@@ -641,6 +647,35 @@
Additional targets may exist in `debian/rules', either as published or
undocumented interfaces or for the package's internal use.
+ The architecture we build on and build for is determined by make
+ variables via dpkg-architecture (see Section 3.1.8). You can get the
+ Debian architecture and the GNU style architecture specification string
+ for the build machine as well as the host machine. Here is a list of
+ supported make variables:
+
+ DEB_*_ARCH the Debian architecture
+ DEB_*_GNU_SYSTEM the GNU style architecture specification string
+ DEB_*_GNU_ARCH the CPU part of DEB_*_GNU_SYSTEM
+ DEB_*_GNU_OS the OS part of DEB_*_GNU_SYSTEM
+
+ where `*' is either BUILD for specification of the build machine or
+ HOST for specification of the machine we build for.
+
+ Backward compatibility can be provided in the rules file by setting
+ the needed variables to suitable default values, please refer to the
+ documentation of dpkg-architecture for details.
+
+ It is important to understand that the DEB_*_ARCH string does only
+ determine which Debian architecture we build on resp. for. It should
+ not be used to get the CPU or OS information, the GNU style variables
+ should be used for that.
+
+ The information provided by the above make variables allows it to
+ cross compile packages. If possible, packages should provide cross
+ compilation support. However, a bug report against missing cross
+ compilation is only acceptable if it is accompanied with a clean
+ patch, and is generally of severity `wishlist'.
+
3.2.2. `debian/control'
-----------------------
@@ -1099,7 +1134,7 @@
4.2.3. `Architecture'
---------------------
- This is the architecture string; it is a single word for the CPU
+ This is the architecture string; it is a single word for the Debian
architecture.
dpkg will check the declared architecture of a binary package against
@@ -1123,21 +1158,8 @@
be a list; if the source for the package is being uploaded too the
special entry `source' is also present.
- The current build architecture can be determined using `dpkg
- --print-architecture'.[1] This value is automatically used by
- dpkg-gencontrol when building the control file for a binary package
- for which the source control information doesn't specify architecture
- `all'.
-
- [1] This actually invokes
- gcc --print-libgcc-file-name
- and parses and decomposes the output and looks the CPU type from
- the GCC configuration in a table in dpkg. This is so that it will
- work if you're cross-compiling.
-
- There is a separate option, `--print-installation-architecture', for
- finding out what architecture dpkg is willing to install. This
- information is also in the output of `dpkg --version'.
+ See section 3.2.1 for information how to get the architecture
+ for the build process.
4.2.4. `Maintainer'
-------------------
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
[EMAIL PROTECTED] for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
