Proposal: Adding more architecture options to dpkg (was: Re: Adding Hurd architecture/os to dpkg and packaging scripts.)
Hello Martin, hello Richard,
thank you for your interest in this matter. I hope I understood everything
and can do the changes soon.
Martin, I edit your mail slightly to incorporate Richards correction :)
On Wed, Jan 06, 1999 at 08:14:52PM +1100, Martin Mitchell wrote:
> > * dpkg --print-installation-architecture
>
> This is the host which is compiling a package.
So this should always match the Debian architecture string (isn't it
unfortunate that we don't use GNU naming convention, *sigh*).
On the hurd, this is "hurd-i386". I noticed that this is a configure option
(--target, or older --with-arch), so I can easily specify this at build time
(when cross compiling). Later, on native compilations, it should default
correctly automatically.
This target is used by process_Archive to determine the architecture during
install, and compare it with the package architecture. It is _hard_coded_ in
the binary at several places (well, it is a static string in the source).
> > * dpkg --print-architecture
>
> This is the target for which a package is being compiled. Often used in
> rules files because it permits cross compiling. For cross compiling from
> linux-i386 to hurd-i386, it will stay the same - i386.
This can't be true, because dpkg-* (the developer scripts) use this target
and put it in the packages (for example, in the changes file). Making this
"i386" on the hurd would break those scripts, in fact, for cross
compilation, we had to use a dpkg wrapper which outputs "hurd-i386" on this
target.
So either your above interpretation is wrong, or the packaging scripts are
broken and should use something similar to "--print-installation-architecture"
instead.
We have a problem here. Up until now, packages always could use the fact
that the gnu-target-architecture is the same as the Debian target
architecture. But with the Hurd, the former is i386, and the latter is
still hurd-i386. Packaging scripts should use Debian target architecture,
and rules files should use "--print-gnu-target-architecture".
How can we solve this? By introducing another option,
"--print-gnu-target-architecture", which can be used in rules files. But,
unfortunately, most rules files are not set up for cross compilation, but
for native compilation, and use the following target in their rules files:
> > * dpkg --print-gnu-build-architecture
>
> This is the gnu version of the target architecture - for example when you do
> gcc -v on i386 linux it reports:
> Reading specs from /usr/lib/gcc-lib/i486-linux/2.7.2.3/specs
> So for i386 the gnu build architecture is i486.
gcc -v on i386 linux reports /usr/lib/gcc-lib/i386-gnu/2.7.2.3/specs, I'm
afraid...
This is a mess :)
> To extend it consistently you want some options like:
>
> dpkg --print-installation-os
>
> OS of the target system. linux or hurd.
We don't need this one, fortunately, because
"--print-installation-architecture" is always the full Debian architecture,
"i386" or "hurd-i386".
> dpkg --print-gnu-build-os
>
> GNU OS of the target system - linux or gnu.
>
> dpkg --print-os
>
> This should return the name of the host os - similar to uname I think.
Again, we would not need such a thing, but a "--print-gnu-target-os".
Package scripts could use the Debian target architecture above.
Summarize: To allow to set up packages for cross compiling, we would need
that:
* dpkg --print-installation-architecture
Returning Debians architecture name, like "i386", "hurd-i386" of the host
system. Dpkg would use that to decide if a package can be installed.
* dpkg --print-target-installation-architecture
Returning Debians architecture name of the package we compile for, like
"i386", "hurd-i386". Package scripts like dpkg-genchanges etc should
_always_ use this, but the default would be the same as
"--print-installation-architecture" (native compile)
* dpkg --print-gnu-build-architecture
The "processor" of the machine we build on. A lot of packages are misusing
this tag to get the target architecture (for example bash is setting $(ARCH)
to that and later it moves directories $(ARCH)-linux around, but this is
_only_ right for native compilation). Packages which can be set up for cross
compilation can use this for the "--build" option to configure.
* dpkg --print-gnu-build-os
This would return "gnu" or "linux" for now, depending on the _HOST_ os.
* dpkg --print-gnu-target-architecture
The "processor" of the machine we build for, eg the target machine.
This should be used in packages scripts where now "gnu-build" is used, as
this is the proper flag. Using this would make it easier to cross compile.
* dpkg --print-gnu-target-os
"linux" or "hurd".
EXAMPLE:
Bash does the following:
ARCH = $(shell dpkg --print-gnu-build-architecture)
SHELL = bash
This would be changed to:
T_ARCH = $(shell dpkg --print-gnu-target-architecture)
T_OS = $(shell dpkg --print-gnu-target-os)
B_ARCH = $(shell dpkg --print-gnu-build-architecture)
B_ARCH = $(shell dpkg --print-gnu-build-os)
T_GNU = $(T_ARCH)-$(T_OS)
B_GNU = $(B_ARCH)-$(B_OS)
if [ "$(B_GNU)" = "$(T_GNU)" ] ; then
SHELL = bash
fi
This would be the proper way to do it.
Later:
build:
$(checkdir)
./configure --host="$(ARCH)-linux" --with-curses
Must be changed to:
build:
$(checkdir)
./configure --host="$(T_GNU)" --build="$(B_GNU)" --with-curses
And similar.
The default behaviour for dpkg would be native compilation, so
print-installation-architecture == print-target-installation-architecture
print-gnu-build-architecture == print-gnu-target-architecture
print-gnu-build-os == print-gnu-target-os
Cross compilers could change the default with a wrapper script (later we can
add configuration files for that, or dpkg-cross supports the wrapper).
This would be slightly more complicated, but MUCH cleaner. Can we implement
this and change policy, so that this way to do it is encouraged (I don't
want to force non-porters to do this themselves, but they should accept good
patches)? What do you think of it? I would like to do a proposal.
I volunteer to do the necessary patches for dpkg and dpkg-dev, if someone
revises them. I think this is very important, our current organization does
not scale very well (ideally, we would use GNU names for debian
architectures, but this would requre reorganizing the ftp archive, which is
"impossible"). The changes required are _very_ small for dpkg. The rules
fies would _still_ work the same, but improve over time. The proposal seems
to be backward compatible to me. Any suggestions are welcome.
I knew that a debian-ports list would be useful to discuss such issues.
Unfortunately, not enough people were for it (or too many listmasters
against). I hope I reach enough interested people through this channel.
Thank you,
Marcus
--
"Rhubarb is no Egyptian god." Debian GNU/Linux finger brinkmd@
Marcus Brinkmann http://www.debian.org master.debian.org
Marcus.Brinkmann@ruhr-uni-bochum.de for public PGP Key
http://homepage.ruhr-uni-bochum.de/Marcus.Brinkmann/ PGP Key ID 36E7CD09
Reply to: