Re: Towards multi-arch: "Multi-Arch: same" file conflicts
Aron Xu <happyaron.xu@gmail.com> writes:
> On Thu, Apr 26, 2012 at 23:21, Osamu Aoki <osamu@debian.org> wrote:
>> Hi,
>>
>> On Sun, Apr 22, 2012 at 03:26:21PM +0200, Julien Cristau wrote:
>>> On Thu, Nov 17, 2011 at 20:03:27 +0100, Jakub Wilk wrote:
>>>
>>> > If a package is marked as "Multi-Arch: same", files with the same
>>> > name have to be (byte-to-byte) identical across all architectures.
>>> > Unfortunately, not all packages obey this requirement. I set up a
>>> > page to track violators:
>>> >
>>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.txt
>>> > http://people.debian.org/~jwilk/multi-arch/same-md5sums.ddlist
>>> >
>>> I've just filed a number of bugs (~60) based on this list, excluding
>>> binNMUed packages and packages affected by #647522.
>>
>> Yep, I got it :-) And you answered to my question:
>>
>>> > Is there any generic solution for GTK girepository files?
>>> >
>>> You should remove the multi-arch: same control field, gir packages are
>>> not ready for multiarch for now.
>>
>> I also see for libopencc1 (not mine but I am watching it...)
>>
>> [libopencc1 0.3.0-2]
>> usr/share/locale/zh_CN/LC_MESSAGES/opencc.mo
>> 2c2024df5378074f4727948eb7133516 mips s390 sparc s390x powerpc
>> 6a7df4d7f1f5383bd7461de8a0bb4957 kfreebsd-amd64 i386 armel armhf ia64 kfreebsd-i386 mipsel amd64
>> usr/share/locale/zh_HK/LC_MESSAGES/opencc.mo
>> 66224514d0c66fd34bfbf95becf8cfd0 kfreebsd-amd64 i386 armel armhf ia64 kfreebsd-i386 mipsel amd64
>> 6c6698b86bbf568baefc414d178108a0 mips s390 sparc s390x powerpc
>> usr/share/locale/zh_TW/LC_MESSAGES/opencc.mo
>> a7fe10a01d59cb26825678bb6c9c2402 kfreebsd-amd64 i386 armel armhf ia64 kfreebsd-i386 mipsel amd64
>> d26ada42ce92c0cea19f4705ca89d433 mips s390 sparc s390x powerpc
>>
>> I guess the solution should be the same for now.
>>
>> For these issies, I wonder 2 things:
>>
>> * These generated non-code data which depend on arch need some generic
>> solution. Is there any wiki-page summarizing these. I understand it
>> is non-trivial thing and it certainly requires cordinated efforts.
>>
>> * If I vaguely remember, I added this for my package due to the lintian
>> warning. We certainly needs to fine tune text so we do not add
>> these.
>>
>> Osamu
>>
>
> So we need to revisit the endianness handling in current M-A design.
> Currently I don't see there are any common way to workaround such
> problem with Gettext .mo files in a package maintainer's point of
> view. Even if we have applied workaround for some other data files
> (install those files under usr/lib/<tripple>), it does not make sense
> for these .mo files. Splitting the files into another arch:any package
> without any M-A fields set does not help, because doing such will make
> the dependent package which has "M-A:same" not co-installable for two
> or more architectures.
My understanding of those gettext files was that gettext generated them
in the hosts endianness but can actualy use them in any endianness. Is
that right? If so then they could be split out into a M-A:foreign and
even Arch:all package.
If the endianness of the data matters (not just for gettext files but in
general) then produce foo-data-<endianness> with Arch:any and
M-A:foreign which install the data files into different subdirs. That
way the data can be shared for the same endianness and both endiannesses
(?) can be co-installed.
MfG
Goswin
Reply to: