On Mon, Mar 2, 2009 at 9:11 PM, Goswin von Brederlow <[email protected]> wrote: > Kov Chai <[email protected]> writes: > >> On Sun, Mar 1, 2009 at 11:11 PM, Goswin von Brederlow <[email protected]> >> wrote: >>> Kov Chai <[email protected]> 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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
