[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Aron Xu

Reply to: