Hi! On Wed, 2011-08-03 at 11:25:37 +0200, Raphael Hertzog wrote: > On Wed, 03 Aug 2011, Michal Suchanek wrote: > > > Note that if your package is "arch: any", you can embed the multiarch > > > path in your package at build time. (This is currently not the case for > > > initramfs-tools) > > > > dpkg is arch:any so it can embed the multiarch architecture at build > > time just like any other package. > > True enough, but it would somewhat duplicate the information. But this > could be acceptable in the mean time I guess. At least better than > embedding it in multiple other packages.
Jonathan already mentioned this, but I'll repeat, I don't really see the point in this, and I don't think this is the right direction to take. I understand it's annoying to not have dpkg-architecture around for maintainer scripts. And duplication is not really desirable, but then those packages do not really need any kind of table nor mapping, just the matching multiarch triplet, which is already known at build time. > The official interface would be "dpkg --print-multiarch-path" and > it would just "cat /usr/lib/dpkg/multiarch-path" that would be created > at build time (and when we have the required code to directly parse > the various /usr/share/dpkg/*table then we can drop that file). Leaving aside the implementation details (I'd rather just define a macro instead), this interface is not good as it only fixes the "problem" for packages matching the dpkg architecture, it will not work at all for foreign architecture packages (including the dpkg crossgrade case). I think the correct solution here is substitution at build time, debhelper already supports this to inject its own snippets, it would be nice to have something like #DEBHELPER_ARCH# and #DEBHELPER_MULTIARCH# for example (or maybe even something more generic). regards, guillem -- To UNSUBSCRIBE, email to debian-dpkg-bugs-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
