Re: Endianness of data files in MultiArch
Aron Xu <happyaron.xu@gmail.com> writes:
> On Sat, Feb 11, 2012 at 00:14, Osamu Aoki <osamu@debian.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.
It also breaks if you export /usr/share to systems of different archs
(nobody actualy does that it seems) and will break with multiarch (far
more likely someone will mix archs there).
>>> 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.
>>
>> Osamu
>
> IMHO it's really bad to maintain such a delta between Debian and upstream.
Depends on the size of the patch. Then again if the patch is small
upstream will probably just include it.
It will just be a matter of waying costs and benefits. How much data is
there? How difficult would it be to convert the data at startup? How
difficult would it be to build a -le and -be data package (on a single
arch)? and so on. There won't be one solution that fits all and I think
there will be packages for each solution presented so far.
MfG
Goswin
Reply to: