Re: Another multiarch decision
- To: Neil Williams <codehelp@debian.org>
- Cc: debian-dpkg@lists.debian.org
- Subject: Re: Another multiarch decision
- From: Goswin von Brederlow <goswin-v-b@web.de>
- Date: Thu, 26 Jun 2008 19:04:45 +0200
- Message-id: <87od5ojff6.fsf@frosties.localdomain>
- In-reply-to: <1214490163.17237.39.camel@holly.codehelp> (Neil Williams's message of "Thu, 26 Jun 2008 15:22:43 +0100")
- References: <87abhde944.fsf@frosties.localdomain> <87tzfhxf8g.fsf@frosties.localdomain> <20080626075348.GQ20886@ouaza.com> <87wskc8idm.fsf@frosties.localdomain> <1214490163.17237.39.camel@holly.codehelp>
Neil Williams <codehelp@debian.org> writes:
> 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.
>...
> 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.
The whole point of multiarch (as opposed to dpkg-cross) is to be able
to run binaries without a clumsy chroot. Running wine, arobat reader,
iceweasel with 32bit plugins, mplayer with win32 codecs, google earth,
skype, ... is a verry real use case. From that side the ability to
cross-compile is purely a bonus.
For me having cross-compiling supported by multiarch is a nice bonus
but not my motivation. But done right we do get it for free which is
verry cool.
>> 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
Doesn't make it legal though.
>> 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
Thanks.
MfG
Goswin
Reply to: