On Thu, 2008-06-26 at 14:56 +0200, Goswin von Brederlow wrote: > Raphael Hertzog <hertzog@debian.org> writes: > > > On Thu, 26 Jun 2008, Goswin von Brederlow wrote: > >> So I think for Multi-Arch: abi packages the /usr/share/doc/<package> > >> in its entirety should be renamed and now there is a choice to make: > > > > I like none of your suggestions. I'd like to suggest to rely on the > > work done by Tollef that lets dpkg skip some files in packages. The first > > purpose was to strip doc and locale data in some embedded usage > > but it could be improved with new rules that exclude such common > > name spaces for package which are for another architecture > > than the current one. > > > > Cheers, > > So when I install iceweasel 32bit on amd64 (for stupid plugins) I will > have no copyright, changelog nor license? I doubt that would be legal. > Even for libaries there is no garanty that the native flavour of a > library will be present when another architectures flavour is > installed. Your use case is a touch unusual (from my perspective anyway) - current behaviour (via dpkg-cross) is focused on only providing the binaries of a particular package for purposes of linking during cross builds, in which case dropping everything not related to linkage is the obvious solution, hence dpkg filtering and dpkg-cross. Similarly, many multiarch dpkg runs will take place in a temporary chroot during a cross-build - there isn't a need for any copyright or changelog files in that situation. (Currently, these -cross packages are generated on-the-fly from the Debian mirrors for the requested architecture, obtained using apt-cross). Actually running foreign binaries involves a different set of problems (and dependencies). iceweasel 32bit on amd64 isn't what I would think of as the typical use of dpkg multiarch support. If we are to continue migrating dpkg-cross into dpkg, the multiarch support will need to support installing ARM packages on amd64 and i386 - not for the purposes of running them via qemu or anything else, purely for the purposes of linking against them during builds. > If a user wants to skip them that is their problem but Debian shipping > a dpkg that skips them allways or by default would be problematic. (Although common in a variety of embedded installations so by no means a deal-breaker.) Besides, dpkg-cross has been in Debian for a decade with the default action doing precisely this kind of stripping: $ dpkg -L libqof1-arm-cross /. /usr /usr/arm-linux-gnu /usr/arm-linux-gnu/lib /usr/arm-linux-gnu/lib/libqof.so.1.0.10 /usr/share /usr/share/doc /usr/share/doc/libqof1-arm-cross /usr/share/doc/libqof1-arm-cross/README /usr/arm-linux-gnu/lib/libqof.so.1 > Can you give me an url for Tollefs work? Maybe that can be used to > rename by default. See this thread in the dpkg list archives: http://lists.debian.org/debian-dpkg/2008/01/msg00001.html And some other links for background: http://www.linux.codehelp.co.uk/serendipity/index.php?/archives/25-dpkg-filtering.html http://www.emdebian.org/docs/howto-4.html -- Neil Williams ============= http://www.data-freedom.org/ http://www.nosoftwarepatents.com/ http://www.linux.codehelp.co.uk/
Attachment:
signature.asc
Description: This is a digitally signed message part