Re: Another multiarch decision

[Goswin von Brederlow <goswin-v-b@web.de>]

Felipe Sateler <fsateler@gmail.com> writes:

> 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.
>> 
>> 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.
>
> Maybe install the first one and skip the next? ie, if I install iceweasel 32
> bits first, then /u/s/d/iceweasel gets installed. When I install the amd64
> version, /u/s/d/iceweasel gets skipped.

And if the first one then gets removed? In dpkg a file belongs to
exactly one package and one package only with the exception of
diversions which add a second package and a second package only.

> Another option would be for dpkg to automatically assume that each arch
> Replaces: the same package for other archs, and so it will just overwrite said
> files.

I'm not sure multiple replaces against each other will work out well
in dpkg. Probably would result in total chaos of file ownership over
time. When some library gets removed random files would disapear while
others remain. Don't like such randomness.

Also other files would replace themself too which is certainly not
wanted. I want to know if a library package ships /usr/bin/foo-helper,
which is a policy violation by the way.

MfG
        Goswin