Re: Towards multi-arch: "Multi-Arch: same" file conflicts
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.
--
Regards,
Aron Xu
Reply to: