Re: Getting the multiarch ball rolling
Hello,
2009/10/11 Simon Richter <Simon.Richter@hogyros.de>:
> I've written a few lines about what emdebian might need wrt. Multiarch.
> Comments and corrections appreciated. (https://wiki.ubuntu.com/MultiarchCross)
Let me copy you here for better review. I shall mark my comments with % tag.
Utilizing Multiarch
Multiarch already goes most of the way by specifying new paths where
libraries are to be found; while the MultiarchSpec lists library -dev
packages as unresolved, the transition plan is already pretty specific
on making binutils and gcc look into multiarch directories, which is
only needed for -dev packages.
% Note that binutils package has not been tough how to look in the
multiarch paths, just gcc (for the suite of compilers).
Some extra work will be required to handle package-config .pc files
(by teaching package-config about the new directories) and
architecture-dependent headers (which are installed below /usr/lib by
several packages). These can be dealt with by patching individual
packages.
% Arch dependent headers are under /usr/include (typo?), we should
propose to add a multiarch like path for headers
(/usr/include/$triplet).
dpkg-cross also handles .pc files. (Need to design a plan for
dpkg-cross -> dpkg merge, Neil?)
As it is for the (current) Multiarch approach, only libraries and
library development files are interesting for the cross-compilation
case. dpkg-cross strips all other files from the generated packages,
so there is no change required there either.
we would like to take up the opportunity to introduce a host/target
distinction in build dependencies in Debian at the same time, even if
Debian itself would not use that information. This would be cheap to
do at this stage, as the dependency handling code needs to be adapted
anyway to handle architecture-qualified dependencies; we propose that
in build dependencies, the special qualifiers ":build" and ":host" can
be appended to package names. When not cross-compiling, these can and
should be treated as if they were not present. The ":any" qualifier
would have the same meaning as for regular dependencies, i.e. it would
allow the dependency to be met by any package with an architecture
that can be executed on the host, regardless of whether that is the
same architecture as the current DEB_BUILD_ARCH.
% Why ":build" and ":host"? I think you need to define what do you
understand by ":build" and ":host" semantics, why not ":target"? Would
not make more sense to use another Build-Dependencies(-Cross) field
for the target (as in GNU definition) case, having a knob to change
dependencies per architecture with "[arch]" tags (is this really
needed)?
Also how do you use this features in the CLI?
Thanks Simon, for the writting and starting this up.
--
Héctor Orón
Reply to: