Re: Building process needs certain architecture's machine

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

Kov Chai <tchaikov@gmail.com> writes:

> On Sun, Mar 1, 2009 at 11:11 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
>> Kov Chai <tchaikov@gmail.com> writes:
>>
>>> Hi all,
>>>
>>> I am packaging sunpinyin. The install script of this software will
>>> identify the endian-ness of the building machine and generate a binary
>>> data file from its architecture independent format. Â And the
>>> executable only works with the data file of appropriate endian-ness.
>>>
>>> So, to minimize the usage of debian mirror space and bandwidth, I
>>> think the best way to package it is to create two more data packages,
>>> one for big-endian, the other for small-endian. The problem is that
>>> the upstream does not provide any way to generate the data file of
>>> specified endian-ness. I also examined the source file only to find
>>> out there is no straightforward way to do it other than to swap the
>>> bits at all the places where the endian-ness kicks in.
>>>
>>> Is there any way to work it out?
>>>
>>> Thanks in advance.
>>
>> The best way would be to patch the source to use architecture
>> independent data. Swap the endianness while you read the file.
>
> Thanks for your suggestion, Goswin. Since the source code will
> generally read/write the file very frequently, swapping the
> endian-ness on the fly would impact its user experience, maybe I can
> write a converter which swaps the endian-ness when the package is
> installed and write the converted binary out to some file in
> /usr/share/sunpinyin.

That's what the ext2 developers thought too a long time ago and ext2
had a little and big endian mode and used the host byte order when
creating an FS. But when they actualy measured performance again a few
years back they decided to just always use the same endianness and
convert on the fly as needed.

In summary: On the fly conversion might not cost as much as you think.

You say the file is read/write very frequently. To me that would
suggest the file would be shipped as /usr/share/sunpinyin/initial-file
and copied to /var/lib/sunpinyin/file in postinst (or on first use).
You MUST NOT write to /usr/.

So keep /usr/share/sunpinyin/initial-file as arch independent file and
in postinst convert it to host order as /var/lib/sunpinyin/file. That
sounds like a verry good approach.

>> Other than that, how big is the file? Is it worth having it split out?
>>
>
> Actually, there are two binary files. One is 6.5 MB, the other is 23.2
> MB. They are basically statistic data. With the tools provided by
> another package (still in RFS), user are allowed to create his/her own
> data files. So I think splitting the data out and making the binary
> package `recommends' the data package would be more flexible from
> user's perspective.

Certainly big enough to warrant the split.

MfG
        Goswin

PS: don't forget about people that switch from say mips (big endian)
to amd64 (little endian) and want to keep their data file. There
should be a converter they can use for that too.