Re: Towards multi-arch: "Multi-Arch: same" file conflicts
On Fri, Apr 27, 2012 at 16:46, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 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.
>
I don't know what's the actual situation of gettext dealing with mo
files, maybe someone else can answer. I'm sure someone who are still
caring about tdeb need to have a look at such problem.
> 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
But what if I endianness does matters for those gettext .mo files?
Installing them as libfoo-translations-be and libfoo-translations-le
will need some change in gettext support of those
applications/libraries, that is finding mo files in alternative paths,
and choosing the right one when being built (cross or not) and run
(host or qemu).
Apart form (possibly) patching the software, marking the library as
M-A:foreign is questionable. How do we specify dependencies in
d/control? If libfoo requires either libfoo-data-be or libfoo-data-le
on different architectures, do we really want to hard code which
architecture to depend on which package manually?
Generating data files for both be and le then making it an arch:all
and M-A:foreign package is not a solution for all maintainers, as this
requires to patch the software which upstream are tend to reject of
inclusion in many cases. Generating such data files in maintainer
scripts is another thing I hate because I believe these data meant to
have checksum stored in the package file list so that users can verify
its integrity when needed.
--
Regards,
Aron Xu
Reply to: