On Sat, 11 Feb 2012 03:28:33 +0200 Riku Voipio <riku.voipio@iki.fi> wrote: > Package proliferation and duplication of arch-independent data are merely > effects that happen when packagers workaround the lack of shared identical > files. +1 > One solution for the binNMU changelogs and generated docs would be to > use arch-qualified paths for those files. That is much more lightweight > solution that arch-qualifying all files, even if identical. > On Fri, Feb 10, 2012 at 11:56:20PM +0100, Guillem Jover wrote: > > For files in M-A:same packages under a pkgname based path, the pkgname > > should always be arch-qualified with the Debian architecture. Most of > > these could be handled automatically by debhelper and cdbs, this includes > > things like: > > > > /usr/share/doc/pkgname/ So this would be everything handled currently by dh_installdocs & dh_installexamples ? > > /usr/share/bug/pkgname > > /usr/share/lintian/overrides/pkgname > > /usr/share/mime-info/pkgname.* > > /usr/share/menu/pkgname > > ... > > I find the requring arch-qualified path for for arch-independent > data ugly system architecture. But of course the beauty of architecture is in > the eye of the beholder (and lets not forget that Unix with its worse-is-better > philosophy[1] was never intended to be architectural masterpiece). > > Personally if leaving out shared files makes you upload multiarch enabled > dpkg to unstable before sagrada familia is complete, i can live it (cursing > silently in my room converting packages to the new requirement...). I can > take the trade-off of having something better-than-current soon over having > the perfect version in distant future... If the changes needed in low-level toolchain-related -dev packages like libc*-dev, linux-libc-dev and libstdc++*-dev are not so onerous for the relevant maintainers that we can actually get a Multi-Arch cross-compiler installed, then (as I've said before), we can use separate build environments per architecture in order to get Multi-Arch into Wheezy, and I'll live with that. One chroot per cross-architecture is workable - as long as there is sufficient support to actually get the cross toolchain installed and operational alongside the native architecture toolchain. It's more important that we get something workable into Wheezy than to have the a broken version in Wheezy and the more elegant solution in Wheezy+1. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgptO_R0jNt0m.pgp
Description: PGP signature