Hello, 2009/10/11 Simon Richter <[email protected]>: > 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
