On Tue, Jun 28, 2011 at 01:44:36AM +0200, Adam Borowski wrote: > On Mon, Jun 27, 2011 at 11:54:53AM +0100, Steve Langasek wrote: > > Multiarch handling of header files (/usr/include) will require > > more per-package attention, because architecture-dependent and > > architecture-independent header files are currently mixed together in a > > single directory and we probably don't want to move these all to > > /usr/include/$arch.
> If a library does install different headers on different architectures, > wouldn't it be better to put everything for the library in /usr/include/$arch? > This way, packaging is much simpler, there is less place for error, headers > for different architectures are co-installable, and there is less confusion. That is one option, for sure; but even determining that a library's headers *are* architecture-dependent is a fairly manual process, so this is going to be much less of an automated process than library handling itself has been. Also, libc6-dev is affected by this, and I'm not sure we really want to move ~400 libc headers to /usr/include/<arch> when only about 20 of them are arch-dependent. > On the downside, files which are the same would be duplicated, but since a > vast majority of libraries use #ifdefs instead of modifying the files, the > waste would be infinitessimally low. I don't know what this "vast majority of libraries" is. Most of the libraries I work on have at least one header that's autogenerated from configure at build time. -- Steve Langasek Give me a lever long enough and a Free OS Debian Developer to set it on, and I can move the world. Ubuntu Developer http://www.debian.org/ slanga...@ubuntu.com vor...@debian.org
signature.asc
Description: Digital signature
