Hi, On Sat, Feb 11, 2012 at 08:40:35AM +0800, Aron Xu wrote: > On Sat, Feb 11, 2012 at 00:14, Osamu Aoki <os...@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.
If it installs into /usr/share ... I agree it is broken. But if postinst installs into /var/lib/<pkg>/... using arch indep text data in /usr/share data, it is OK. Just a bit too much data duplication, though. > 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. > > > > Agreed. > > >> 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. I agree and I do not think I want to do that. Regards, Osamu -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20120211054808.GB29621@localhost