Re: Building process needs certain architecture's machine

[Kov Chai <tchaikov@gmail.com>]

On Mon, Mar 2, 2009 at 9:11 PM, Goswin von Brederlow <goswin-v-b@web.de> wrote:
> 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.
>
Great. I will take a closer look at the code to see if I can do it in
a neat way.

> 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/.
>
Sorry, my mistake, the data files are only "read" by the software.

> 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.
>

So I can put the converted file at /usr/share/sunpinyin/converted-file
in postinst?

>>> 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.
>

Good point! If we use the convert-while-install way, this converter is
also a must.

Thanks a lot.

-- 
Regards
Kov Chai