Re: Endianness of data files in MultiArch
On Sat, Feb 11, 2012 at 00:14, Osamu Aoki <firstname.lastname@example.org> wrote:
> Just think any phrase data with its content size in 16bit integer.
> I have bigger example :-)
> ipadic: Uncompressed size: 44.5 M
> This one, I made them arch:any to build many binary packages. Similar
> packages use install time conversion trick to keep them "arch: all" but
> this install takes time.
This trick is broken. Dpkg doesn't have similar features like `rpm -V`
at present, which verifies if files on disk are identical to what was
installed. I believe it's useful and will land in dpkg someday (but
don't ask me for patch now...). By coverting data files at user's
install, it breaks when the package manager verifies the file's
integrity. I prefer to use more mirror space to doing such thing if I
have to choose between them, which is the current status.
> I think PO files cases are manageable. They can use one endianess for
> all platform.
> But for any other generic special purpose natural language processing
> code, it is impossible to force upstream to complicates code to use
> particular endianness.
>> So unless the program is restarted for every input (which would be the
>> first thing to eliminate to improve responsiveness) there shouldn't be a
>> problem with "fixing" this. It just means extra work you might not be
>> willing (or have time) to invest.
> If we are ready to rewite core of such code, you are right. But if we
> simply accept upstream code design, we will endup making multiple of
> such semi-arch depended data in archive as arch: any.
IMHO it's really bad to maintain such a delta between Debian and upstream.