[ note that this is CC to debian-devel, because it originated there. follow
up's to debian-policy(?) ]
DRAFT: Fixing the architecture query options of dpkg, Version 0.1
=================================================================
Abstract: I hope that we can make it easier and clearer how different
architectures can be supported in one rules file, even beyond Linux.
Furthermore, we gain the possibilty for cross compilation support in rules
files almost "for free".
Terms (skip them if you are lazy, and come back for special terms):
=====
Debian Installation Architecture (short: Debian Arch)
Is used to organize the ftp archive and sepereates the individual
ports. Can be one of i386,alpha,sparc,...,hurd-i386.
GNU System Type
Is used to determine the exact specifications of a machine for
software compiling. It consists of two (in general three) parts, the
cpu, (an optional vendor tag) and a operating system specification,
seperated by hyphens. For example, i386-linux would describe the Debian
Arch i386, i386-gnu the Debian port hurd-i386.
GNU Arch
The cpu part of a GNU System Type.
Valid are i386,alpha,sparc,...
GNU OS
The OS part of a GNU System Type.
Valid are linux and gnu.
Build System, Host System
The machine a package is build on (is a GNU System Type or a Debian Arch,
depending on context).
Target System
The machine a package will be installed and run on (is a GNU System Type
or a Debian Arch, depending on context).
Cross Compilation
If the Target System and the Build System are different, we are doing
cross compilation.
Current Options
===============
--print-installation-architecture
Returns the Debian Arch of the host system, that means the machine dpkg is
running on. A package can be installed on the host system if the Debian
Arch of the package matches this string.
--print-architecture
As I was told, this is the Debian Arch of the target machine.
--print-gnu-build-architecture
Returns the GNU Arch of the host system.
Problems
========
We see that there is neither a clear seperation of OS type (gnu or linux),
nor a clear seperation between target and build system type. My experiences
in the hurd-i386 port verify that a lot of changes are necessary to allow
cross compilation of a package, including removing/replacing hard coded
GNU OS strings like "-linux", and using the Debian Arch as GNU Arch.
This proposal aims at a clearer distinction between the different cases
and the necessary infrastructure in dpkg.
Furthermore, the --print-architecture option is troublesome. First, it does
not tell what it does from the name, so the name was choosen unlucky.
Furthermore, and this is the real problem, it returns a Debian Arch and not
a GNU System arch. Up until now, this was not a real issue, because you
could always get the GNU System by adding "-linux" to the Debian Arch. This
is not true anymore since Debian GNU/Hurd popped up into existence.
Hardcoding these mappings in the individual packages is also bad design, but
was necessary until now because dpkg lacks options.
I therefore propose the use of the following set of options:
Proposed Options
================
--print-installation-architecture
Stays the same. (Later, we can make it returning a _list_ of installable
Debian Archs. This is for systems which support multiple Debian ports, like
sparc64 (supporting sparc) and pentium (supporting i386), or even hurd-i386
(supporting i386 with Linux binary compatibility)
--print-target-installation-architecture
Returns the target Debian Arch for package building. Normally, this would
be the same as "--print-installation-architecture" (default), but for
cross compilation, you could change dpkg (for example by diversion) to
return a different Debian Arch.
--print-gnu-build-architecture
Returns the GNU Arch of the host=build system.
--print-gnu-build-os
Returns the GNU OS of the host=build system.
--print-gnu-target-architecture
Returns the GNU Arch of the target system we build for. Per default, this
is the same as --print-gnu-build-architecture, but can be changed for cross
compilation.
--print-gnu-target-os
Returns the GNU OS of the target system we build for. Per default, it is
the same as --print-gnu-build-os, but can be changed for cross compilation.
Note that, if ARCH is the output of --print-gnu-build-architecture and OS
the output of --print-gnu-build-os, you get a valid GNU System Type by
cat'ing them together with a hyphen, eg $(ARCH)-$(OS), which can be passed
directly to configure. Hence, a good alternative would be to provide just
two options, --print-gnu-build-system and --print-gnu-target-system, which
returns the complete string directly. A single --print-gnu-build-architecture
could be provided for backward compatibility, too.
For backward compatibility:
--print-architecture
Should do whatever it does now. Maybe an alias for
"--print-target-installation-architecture"
Rationals, consequences etc
===========================
The changes that are needed would be minimal. Adding the options to dpkg,
and changing the building scripts in dpkg-dev to use
--print-target-installation-architecture instead --print-architecture
would suffice. No further changes are _required_.
Package rules files would be changed to support cross compilation over time,
the existing scripts will continue to work in the same way they do now, and
can only improve. I don't think this should be enforced (as not every
packager knows about cross compiling facilities, and some packages really
can't be cross compiled easily), but porters should submit patches and the
maintainers should consider the patches and incorporate them into the rules
files (the idea is that we have lots of time to make the transition).
Backward compatibilty: All old options continue to output what they output
now. If maintainers are concerned about using the new options in their
packaging scripts, they can catch dpkg's exit code and fall back to a
sensible default value.
If dpkg doesn't understand... use instead...
--print-target-installation-architecture --print-installation-architecture
(or --print-architecture??)
--print-gnu-build-os "linux"
--print-gnu-target-* --print-gnu-build-*
This way, no existing functionality is lost, and new rules files will
continue to work with old versions of dpkg and friends!
My proposal offers a clean seperation of Debian and GNU naming convention
and of build and target architectures. I would volunteer to write the
necessary changes for dpkg and friends, and I will also send in patches for
maintainers of packages to support the new features.
Common cases of current incompatibilities which would be resolved:
* Using $(ARCH)-linux in their packaging script.
* Using ARCH = --print-gnu-build-target and then using the very same string
as Debian Arch name (which breakes if the OS is not linux, but hurd)
Special things were I would appreciate input
============================================
What exactly was the original meaning of "--print-architecture", and how
does it fit in my new scheme? In my new scheme, it is obsolete, mainly
because I don't know for certain what it does (I know it is used by package
building scripts to determine the Debian Arch,but it is also used randomly
in other places).
Should we go the way of seperate gnu-*-architecture and gnu-*-os query options,
or
should we use gnu-*-system options which combine both? The individual
components are seldom needed, and can easily be extracted from the
gnu-*-system string. This would make the proposal a bit easier, as we only
would have three new options, and not four (and two obsolete options for
backward compatibilty, instead one).
If you want an example, I could for example rewrite the bash rules files to
follow my new setup, and you can look at the difference. Just let me know if
my words were not descriptive enough for you (one example says more than
thousands words, but this mail is really long enough, so I will wait for
your suggestions and requests).
I hope you realize that I don't want unnecessary complication of the
packaging tools. I think my proposal will make it easier to write rules
files that support all architectures, and, this issue has to be resolved in
one way or another. The alternative would be to hard code the translation of
hurd-i386 -> i386-gnu in each rules file, which would be very ugly!
If no one has serious concerns, I will make this an official proposal, soon.
For now, I just want to gather some more information. For the official
proposal, I will have to dig out the relevant sections in our policy and
provide replacement text.
Thank you,
Marcus
--
"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
