Bug 575005

Hi Chen Lei,
  I tried to build this package on arch i386, but rpmlint reports that this
package has no binary file, and this package should be noarch.
  Build this package as noarch, to avoid this error of rpmlint.

  I don't know whether the model is arch-dependent, or not-dependent.
  If the model file is arch-dependent, how could we fixes the error which is
reported by rpmlint?
  Or just merge the model files into zinnia rpm packages as they are from the
same project?

Note:

%{_libdir} differs between %ix86 and x86_64. If the directory
where models are to be installed is arch-dependent (i.e.
differ between %ix86 and x86_64), this package must not be
noarch, even though rpmlint complains.

Hi Mamoru Tasaka,
  Could I just ignore this error reported by rpmlint?
  Will it be accepted in koji with this error report?
  I thought that rpmlint error can't be ignored in the past.
Thanks,

This package is noarch. I think maybe you can use ./configure instead of %configure macro by passing an argument --libdir=%{_datadir} to cheat it. 


CFLAGS="${CFLAGS:-%optflags}" ; export CFLAGS ; 
  CXXFLAGS="${CXXFLAGS:-%optflags}" ; export CXXFLAGS ; 
  FFLAGS="${FFLAGS:-%optflags -I%_fmoddir}" ; export FFLAGS ; 
  ./configure --build=%{_build} --host=%{_host} \
	--target=%{_target_platform} \
	--program-prefix=%{?_program_prefix} \
	--prefix=%{_prefix} \
	--exec-prefix=%{_exec_prefix} \
	--bindir=%{_bindir} \
	--sbindir=%{_sbindir} \
	--sysconfdir=%{_sysconfdir} \
	--datadir=%{_datadir} \
	--includedir=%{_includedir} \
	--libdir=%{_datadir} \
	--libexecdir=%{_libexecdir} \
	--localstatedir=%{_localstatedir} \
	--sharedstatedir=%{_sharedstatedir} \
	--mandir=%{_mandir} \
	--infodir=%{_infodir}

Well, I tried to rebuild this pkg and actually handwriting-ja.model
differs between archs (perhaps endian specific), so this pkg must
not be noarch.

$ find . -name \*ja.model | sort | xargs md5sum
03c61b0424c5fdb96bf0e5f904259d5b  ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.i686/usr/lib/zinnia/model/tomoe/handwriting-ja.model
e29a1670db551246a0ebd076b301f329  ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc/usr/lib/zinnia/model/tomoe/handwriting-ja.model
e29a1670db551246a0ebd076b301f329  ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc64/usr/lib/zinnia/model/tomoe/handwriting-ja.model
03c61b0424c5fdb96bf0e5f904259d5b  ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.x86_64/usr/lib/zinnia/model/tomoe/handwriting-ja.model

(note that in Makefile.am in the tarball of this pkg, "modeldir"
 is hardcoded as @prefix@/lib/zinnia/model/tomoe , however this
 needs fixing because we request that arch-specific pkg must use
 %_libdir, not /usr/lib )

Or maybe it is better that you ask the upstream that zinnia_convert
should return arch-independent model file regardless of endianness,
however anyway without it this pkg must be arch-specific.

(In reply to comment #6)
> Or maybe it is better that you ask the upstream that zinnia_convert
> should return arch-independent model file regardless of endianness,
> however anyway without it this pkg must be arch-specific.    

The model-file is arch-dependent, so you are right.

From http://zinnia.sourceforge.net, they wrote "text-model is an architecture-independent format, and model-file is an architecture-dependent binary model. Zinnia recognizer can only load binary model. zinnia_convert program converts text-model into binary model."

Here are the new version of zinnia-tomoe package:
Spec URL: http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe.spec
SRPM URL:
http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe-0.6.0.20080911-2.fc12.src.rpm
Please review this new package, thanks in advance.

Here are the summary of changes:
As the model data in this package is arch-dependant, built this package as arch-dependant too.
And fixed the model data path in the Makefile.am:
-modeldir   = @prefix@/lib/zinnia/model/tomoe
+modeldir   = @libdir@/zinnia/model/tomoe

There is a known rpmlint error report, which said the package should be noarch.
Currently I can't work around this rpmlint report, just ignore it. 
Alternatively maybe we can merge the model file to zinnia package as a sub-package?

(In reply to comment #8)
> Here are the new version of zinnia-tomoe package:
> Spec URL: http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe.spec
> SRPM URL:
> http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe-0.6.0.20080911-2.fc12.src.rpm
> Please review this new package, thanks in advance.
> Here are the summary of changes:
> As the model data in this package is arch-dependant, built this package as
> arch-dependant too.
> And fixed the model data path in the Makefile.am:
> -modeldir   = @prefix@/lib/zinnia/model/tomoe
> +modeldir   = @libdir@/zinnia/model/tomoe
> There is a known rpmlint error report, which said the package should be noarch.
> Currently I can't work around this rpmlint report, just ignore it. 
> Alternatively maybe we can merge the model file to zinnia package as a
> sub-package?    

1.rpmlint error can be ignored, you shoud add %global debug_package %{nil} in the specfile.
See http://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons
2.
Version:        0.6.0.20080911
Release:        2%{?dist}->
Version:        0.6.0
Release:        2.20080911%{?dist}
I think 20080911 should be added to the release field.
3.
License field is not right.
See http://tomoe.svn.sourceforge.net/viewvc/tomoe/tomoe/trunk/COPYING?revision=369&view=markup

(In reply to comment #9)
> 2.
> Version:        0.6.0.20080911
> Release:        2%{?dist}->
> Version:        0.6.0
> Release:        2.20080911%{?dist}
> I think 20080911 should be added to the release field.

I think Release field is for fedora rpm release number, and it is not upstream release number. So I think "Release:        2%{?dist}" is OK.

> 1.rpmlint error can be ignored, you shoud add %global debug_package %{nil} in
> the specfile.
> See
> http://fedoraproject.org/wiki/Packaging:Debuginfo#Useless_or_incomplete_debuginfo_packages_due_to_other_reasons

Added %global debug_package %{nil} to spec file.

> 3.
> License field is not right.
> See
> http://tomoe.svn.sourceforge.net/viewvc/tomoe/tomoe/trunk/COPYING?revision=369&view=markup    

Change license field to LGPLv2+.

Bumped the release number.

Here are the new package for reviewing:
Spec URL: http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe.spec
SRPM URL:
http://pwu.fedorapeople.org/zinnia-tomoe/zinnia-tomoe-0.6.0.20080911-3.fc12.src.rpm

(In reply to comment #10)
> (In reply to comment #9)
> > 2.
> > Version:        0.6.0.20080911
> > Release:        2%{?dist}->
> > Version:        0.6.0
> > Release:        2.20080911%{?dist}
> > I think 20080911 should be added to the release field.
> 
> I think Release field is for fedora rpm release number, and it is not upstream
> release number. So I think "Release:        2%{?dist}" is OK.    

Because there is a dash(-) between 0.6.0 and 20080911, so I think it may be better to add 20080911 to the release field. But it's not a block thing for package review, and the final decision is up to you.

(In reply to comment #5)
> Well, I tried to rebuild this pkg and actually handwriting-ja.model
> differs between archs (perhaps endian specific), so this pkg must
> not be noarch.
> 
> $ find . -name \*ja.model | sort | xargs md5sum
> 03c61b0424c5fdb96bf0e5f904259d5b 
> ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.i686/usr/lib/zinnia/model/tomoe/handwriting-ja.model
> e29a1670db551246a0ebd076b301f329 
> ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc/usr/lib/zinnia/model/tomoe/handwriting-ja.model
> e29a1670db551246a0ebd076b301f329 
> ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc64/usr/lib/zinnia/model/tomoe/handwriting-ja.model
> 03c61b0424c5fdb96bf0e5f904259d5b 
> ./zinnia-tomoe-0.6.0.20080911-1.1.fc12.x86_64/usr/lib/zinnia/model/tomoe/handwriting-ja.model
> 
> (note that in Makefile.am in the tarball of this pkg, "modeldir"
>  is hardcoded as @prefix@/lib/zinnia/model/tomoe , however this
>  needs fixing because we request that arch-specific pkg must use
>  %_libdir, not /usr/lib ) 
Hi Mamoru,

Should we install endian-specific files into /usr/lib or /usr/share instead of %{_lib}? Because there are no difference between 32bit and 64bit files, though the files are arch-specific. There are only two types of endian-specific files - little endian and big endian.

I need your help, because another package review also has endian-specific files.

As
http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
/usr/share is arch-dependent files only, so if the files differ between
endianness, the files cannot be under /usr/share.

Also while it seems model files are endian-dependent, I am not sure
if zinnia_convert surely always reproduce the same model file if
the endianness is the same. If the upstream just says
"model file is arch-dependent", it is safer to use %_libdir, not
%prefix/lib.

(In reply to comment #14)
> As
> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRSHAREARCHITECTUREINDEPENDENTDATA
> /usr/share is arch-dependent files only, so if the files differ between
> endianness, the files cannot be under /usr/share.
> Also while it seems model files are endian-dependent, I am not sure
> if zinnia_convert surely always reproduce the same model file if
> the endianness is the same. If the upstream just says
> "model file is arch-dependent", it is safer to use %_libdir, not
> %prefix/lib.    
$ find . -name \*ja.model | sort | xargs md5sum
03c61b0424c5fdb96bf0e5f904259d5b 
./zinnia-tomoe-0.6.0.20080911-1.1.fc12.i686/usr/lib/zinnia/model/tomoe/handwriting-ja.model
e29a1670db551246a0ebd076b301f329 
./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc/usr/lib/zinnia/model/tomoe/handwriting-ja.model
e29a1670db551246a0ebd076b301f329 
./zinnia-tomoe-0.6.0.20080911-1.1.fc12.ppc64/usr/lib/zinnia/model/tomoe/handwriting-ja.model
03c61b0424c5fdb96bf0e5f904259d5b 
./zinnia-tomoe-0.6.0.20080911-1.1.fc12.x86_64/usr/lib/zinnia/model/tomoe/handwriting-ja.model

It seems the model files have the same md5 between ppc and ppc64(also between i686 and x86_64).
I'll try to build those file in arm to determine whether those model files are just endian-dependent. 
debian guys treat those model files as noarch.
See http://packages.debian.org/sid/all/tegaki-zinnia-japanese

Note that whether zinnia_convert-generated model files are only
endian-dependent or not must be judged by examining source codes,
not by checking rebuilt binaries.

Anyway this package cannot be noarch (I don't know debian's policy,
however debian's policy cannot be applied here)

(In reply to comment #16)
> Note that whether zinnia_convert-generated model files are only
> endian-dependent or not must be judged by examining source codes,
> not by checking rebuilt binaries.
> Anyway this package cannot be noarch (I don't know debian's policy,
> however debian's policy cannot be applied here)    

Now I can confirm those model files are endian-specific only, and I think it should be placed in /usr/share, because I find that linux distributions normally place endian-sepcific data file under /usr/share.
See:
pwd
/usr/share/locale/de/LC_MESSAGES

file yum.mo
yum.mo: GNU message catalog (little endian), revision 0, 481 messages

No.

The reason gettext .mo files are put under /usr/share is because
these gettext .mo files have little endianness even on ppc/ppc64
architecture (i.e. msgfmt generates little endian data file regardless
of the architecture of the system)

$ pwd
/home/tasaka1/rpmbuild/RPMS/ppc/gettext-0.17-16.fc12.ppc/usr/share/locale/ja/LC_MESSAGES
$ file gettext-runtime.mo 
gettext-runtime.mo: GNU message catalog (little endian), revision 0, 42 messages

Again files under /usr/share must be arch-independent.

(In reply to comment #18)
> No.
> 
> The reason gettext .mo files are put under /usr/share is because
> these gettext .mo files have little endianness even on ppc/ppc64
> architecture (i.e. msgfmt generates little endian data file regardless
> of the architecture of the system)
> 
> $ pwd
> /home/tasaka1/rpmbuild/RPMS/ppc/gettext-0.17-16.fc12.ppc/usr/share/locale/ja/LC_MESSAGES
> $ file gettext-runtime.mo 
> gettext-runtime.mo: GNU message catalog (little endian), revision 0, 42
> messages
> 
> Again files under /usr/share must be arch-independent.    

You are right if we follow on FHS seamlessly. But in practice, there are a lot of packages install endian-specific data under %{_datadir}.
e.g.
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1511536&filename=/usr/share/supertux/locale/messages.pot
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1511530&filename=/usr/share/supertux/locale/messages.pot
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1511532&filename=/usr/share/supertux/locale/messages.pot
You can also take a look at #570731, the default path for those model files are %{_datadir}. The only thing I can confirm is this package is architecture-dependent and we cannot add noarch for this package. I think maybe we should be lenient for installing endian-specfic data into %{_datadir}. BTW, modern ppc and sparc machines are actually Bi-endianness and able to treat little-endian data.

Again no. We must follow FHS:
https://fedoraproject.org/wiki/Packaging/Guidelines#Filesystem_Layout

pot files are just plain texts and so arch-independent. Usually the
difference between these pot files are because the time when these
pot files are generated are embedded in pot files themselves:

$ diff -u ./supertux-0.3.1-9.fc12.x86_64/usr/share/supertux/locale/messages.pot ./supertux-0.3.1-9.fc12.ppc64/usr/share/supertux/locale/messages.pot
--- ./supertux-0.3.1-9.fc12.x86_64/usr/share/supertux/locale/messages.pot       2009-08-26 15:45:50.000000000 +0900
+++ ./supertux-0.3.1-9.fc12.ppc64/usr/share/supertux/locale/messages.pot        2009-08-26 15:48:41.000000000 +0900
@@ -8,7 +8,7 @@
 msgstr ""
 "Project-Id-Version: PACKAGE VERSION\n"
 "Report-Msgid-Bugs-To: \n"
-"POT-Creation-Date: 2009-08-26 02:45-0400\n"
+"POT-Creation-Date: 2009-08-26 02:48-0400\n"
 "PO-Revision-Date: YEAR-MO-DA HO:MI+ZONE\n"
 "Last-Translator: FULL NAME <EMAIL@ADDRESS>\n"
 "Language-Team: LANGUAGE <LL>\n"

not due to endianness. Again /usr/share is arch-independent file
only, and Fedora follows FHS.

Some more packages that put endian-specific data into %{_datadir}:

http://koji.fedoraproject.org/koji/fileinfo?rpmID=1731290&filename=/usr/share/espeak-data/mk_dict
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1731299&filename=/usr/share/espeak-data/mk_dict
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1731296&filename=/usr/share/espeak-data/mk_dict
http://koji.fedoraproject.org/koji/fileinfo?rpmID=1731293&filename=/usr/share/espeak-data/mk_dict


I really want to put arch-specific files into directories other than %{_datadir}, however I think we should treat endian-specific files seriously and follow packaging convention. We cannot simply consider endian-specific data as arch-specific, because little-endian data and big-endian data are just the counterpart of the other through byte swapping. I'll try to find more examples on how to treat endian-specific files, or is it right to ask FPC's opinion on how to treat those data? If we decide to put all endian-specific data into {_libdir} or /usr/lib, maybe we need to patch a large amount of packages that already existed in the repo of fedora.

I don't know if espeak packaging has a bug or so, however
as I repeatly say we must follow FHS and arch-specific data cannot
be under /usr/share. "Because other packages have some buggy packaging"
is no execute. period.

(In reply to comment #22)
> I don't know if espeak packaging has a bug or so, however
> as I repeatly say we must follow FHS and arch-specific data cannot
> be under /usr/share. "Because other packages have some buggy packaging"
> is no execute. period.    

This may be not a packging bug, the endianness-specific data(little and big endian) itself is arch neutral and read-only, and cannot consider as arch-dependent simply.  As you already point out that gettext .mo files have little endianness even on ppc/ppc64 arches, so it's eentirely possible to write a program that can utilize little-endian model-files in ppc/ppc64.

I talked with a developer of sunpinyin(http://code.google.com/p/sunpinyin/) and he recommend me to split endian-specific file into two noarch package(little and big endian), then create a arch-dependent metapackage to require different packages in different arch. 
Note: sunpinyin have two big endianess-specific files(nearly 30MB).

Zinnia-tomoe is only require by ibus-handwrite now, ibus-handwrite hardcodes the path to the model files in its source code. It's not easy to write a patch for ibus-handwrite to switch its path from {_datadir} to /usr/lib or {_libdir}.

> so it's eentirely possible to write
> a program that can utilize little-endian model-files in ppc/ppc64.

I already said so in my comment 6 (and also in my comment 18)

_Again_ if zinnia_convert generates arch-independent data and 
ibus-handwrite (for now) can read such data
- for example ibus-handwrite on i686 can read the files correctly the
  generated by ppc zinna_convert, 
this package can just be "noarch". This requires rewrite of both zinnia-utils
and ibus-handwrite. 
! Note that this is not only gettext. For example python's byte-compiling
  does the same thing.

> I talked with a developer of sunpinyin(http://code.google.com/p/sunpinyin/) and
> he recommend me to split endian-specific file into two noarch package(little
> and big endian), then create a arch-dependent metapackage to require different
> packages in different arch. 
> Note: sunpinyin have two big endianess-specific files(nearly 30MB).

In such cases. the generated model files should have names which are
endian-specific (e.g. handwriting-foo.model.little_endian, for example),
and ibus-handwrite (currently only this?) should be patched to require
endian specific file.

Can't we just make the package arch and put the datafiles under libdir for now?

(In reply to comment #25)
> Can't we just make the package arch and put the datafiles under libdir for now?    

I already solved this issues by split this package to two noarch subpackage - zinnia-tomoe-el and zinnia-tomoe-eb. But ibus-handwrite don't depend on this package now. So I don't know if we are worth to do so.

(In reply to comment #26)
> (In reply to comment #25)
> > Can't we just make the package arch and put the datafiles under libdir for now?    
> 
> I already solved this issues by split this package to two noarch subpackage -
> zinnia-tomoe-el and zinnia-tomoe-eb. But ibus-handwrite don't depend on this
> package now. So I don't know if we are worth to do so.


Hello Chen Lei,
Where can I find your package for zinnia-tomoe-el and zinnia-tomoe-eb? 
And how could I compile these noarch packages on koji from textual model file model.txt?

(In reply to comment #27)
> (In reply to comment #26)
> > (In reply to comment #25)
> > > Can't we just make the package arch and put the datafiles under libdir for now?    
> > 
> > I already solved this issues by split this package to two noarch subpackage -
> > zinnia-tomoe-el and zinnia-tomoe-eb. But ibus-handwrite don't depend on this
> > package now. So I don't know if we are worth to do so.
> Hello Chen Lei,
> Where can I find your package for zinnia-tomoe-el and zinnia-tomoe-eb? 
> And how could I compile these noarch packages on koji from textual model file
> model.txt?    

Since ibus-handwrite don't require zinnia anymore, would you still want to import this package into repo?
See https://bugzilla.redhat.com/show_bug.cgi?id=570731

Zinnia-tomoe-el and zinnia-tomoe-eb subpackages can be built easily.
Using %ifarch %{ix86} x86_64 arm5tel for zinnia-tomoe-el and %else for zinnia-tomoe-eb

Note: 
1.zinnia-tomoe-el should conflict with zinnia-tomoe-eb.
2.adding noarch for subpackges, not for zinnia-tomoe

What is the advantage of having two separate noarch packages
over just using libdir?

I think without zinnia, ibus-handwrite is not usable. The correct rate is too low.

(In reply to comment #29)
> What is the advantage of having two separate noarch packages
> over just using libdir?

Maybe could save some space in yum repositories server. I don't know if it has other advantages.

I suggest just putting data file in libdir; or fixing zinnia code to make the data arch independent.

(In reply to comment #30)
> I think without zinnia, ibus-handwrite is not usable. The correct rate is too
> low.    

It seems the git snapshot of ibus-handwrite cannot use zinnia engine anymore, it should be confirmed with with ibus-handwrite author again whether the next release can use zinnia.

(In reply to comment #29)
> What is the advantage of having two separate noarch packages
> over just using libdir?    

Model files are rather big files and opened by zinnia. The model files are just endian-specific instead of strict arch-specfic. Having noarch packages and installing them into /usr/lib or /usr/share can reduce download time and save space for 64bit arch if someone wants to install both 32bit and 64bit zinnia.

Hmm why would a typical use need multiarch zinnia?

Seems to me easier just to make this package arch.

Reading though this it will be simpler for long term management for this to be architecture specific. rpm doesn't understand endianness and trying to shoehorn it in makes it much more complicated and difficult to work with.

 
(In reply to comment #34)
> Hmm why would a typical use need multiarch zinnia?
> Seems to me easier just to make this package arch.    

Zinnia are shlibs, so we should consider multilib issues.
http://download.fedora.redhat.com/pub/fedora/linux/updates/12/x86_64/zinnia-0.05-4.fc12.x86_64.rpm
http://download.fedora.redhat.com/pub/fedora/linux/updates/12/x86_64/zinnia-0.05-4.fc12.i686.rpm

Actually there are no package guideline items for endian-specfic files, and I found many packages treat those files as noarch and install them into %{_datadir}.

(In reply to comment #35)
> Reading though this it will be simpler for long term management for this to be
> architecture specific. rpm doesn't understand endianness and trying to shoehorn
> it in makes it much more complicated and difficult to work with.    

Where should we install those endian-specfic files %{_prefix}/lib, %{_datadir} or %{_libdir}? The default install path for those files are normally %{_datadir} and many softwares which utilize endian-specfic data hardcode /usr/share/%{name} in its code. It'll be a bit complicated to patch some package to install or utilize those files from %{_datadir} to %{_libdir}.

If and only if you can use big endian data on a little endian system or little endian data on a big endian system you can put it in %{_datadir}
  because while the data references the endianness its created on it is architecture independent. 

In your case the data it seems can not be used cross endian and so it is architecture dependent and must go in %{_libdir}

(In reply to comment #37)
> (In reply to comment #35)
> > Reading though this it will be simpler for long term management for this to be
> > architecture specific. rpm doesn't understand endianness and trying to shoehorn
> > it in makes it much more complicated and difficult to work with.    
> 
> Where should we install those endian-specfic files %{_prefix}/lib, %{_datadir}
> or %{_libdir}? The default install path for those files are normally
> %{_datadir} and many softwares which utilize endian-specfic data hardcode
> /usr/share/%{name} in its code. It'll be a bit complicated to patch some
> package to install or utilize those files from %{_datadir} to %{_libdir}.    

I think it is acceptable to install arch specified *DATA* files in %{_datadir}
too. Probably we can not find out a 100% perfect solution right now, but I
think we could improve it in future. I still suggest resolving this problem in
upstream. Let zinnia use non endian-specific data file.

BTW, I think our major platfroms (i386 and x86_64) using the same endian.

(In reply to comment #38)
> If and only if you can use big endian data on a little endian system or little
> endian data on a big endian system you can put it in %{_datadir}
>   because while the data references the endianness its created on it is
> architecture independent. 
> In your case the data it seems can not be used cross endian and so it is
> architecture dependent and must go in %{_libdir}    

For this package its easy to fix because all data files are arch specfic. 

If we decide to fix some other fedora packages(normally input method db, game data, voice db and etc.), it'll be very complicated.

e.g.
espeak http://koji.fedoraproject.org/koji/rpminfo?rpmID=1829417

It contain both noarch files and endian-specfic data files, the default install path for those files are {_datadir}/%{name}-data. The source code defines a macro for its datadir, if we simply cheat dadadir macro to {_libdir}, then we need to install all other noarch files to %{_libdir} too. Also according to FHS, lib64 is designed for 64bit libraries, it seems more reasonable to install those data files to /usr/lib instead of %{_libdir}.

You are readding way to litterally the files on the filesystem.  lots of applications show the endianess of the architecture that it was created on.  but the applications deals with it just fine regardless of what it was created on. 

until such point as your application deals with them being created on any arc/endianess,  it is application specific data  that is architecture dependent and as such belongs in %{_libdir}/%{name}/

The data is not architecutre dependent. It should be endian dependent. If different architectures blog to the same endian, the package can share with another architectures. An x86_64 users does not want to install a package in order to keep compatibie if it is not recommended, because an extra package means it will take more spaces. 

I wrote a spec sample for zinnia-tomoe. It will be built independently for little-endian and big-endian. 

https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe-sample.spec

And I modify the zinnia-tomoe-fixes-makefile.patch. The default installation path will switch to %{_datadir}. 

Here is koji result:
http://koji.fedoraproject.org/koji/taskinfo?taskID=2132276
SPEC:
https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe.spec
SRPM:
https://dl.dropbox.com/u/1352061/zinnia-tomoe/zinnia-tomoe-0.6.0.20080911-4.fc12.src.rpm

As we know, maintaining source codes is much more difficult to maintain spec files, especially for me, not an professional coder. For many packagers, they have no enough skill to modify the codes. So we can see the best way to modify the spec file under packaging guideline. If we put endian-dependent data to %{_libdir}, it will mean that quite many package should be requested to change their codes. Comparing to codes, it is an easy job to edit spec files. At last, in my opinion, Fedora should have a new guideline to teach packagers how to build a endian-dependent package.

I created a patch to modify zinnia to always use little endian for data file. Please ref bug https://bugzilla.redhat.com/show_bug.cgi?id=585161 .

I also sent a patch review to zinnia's author. Wish it could be applied soon.

(In reply to comment #43)
> I created a patch to modify zinnia to always use little endian for data file.
> Please ref bug https://bugzilla.redhat.com/show_bug.cgi?id=585161 .
> 
> I also sent a patch review to zinnia's author. Wish it could be applied soon.    

Peng Huang, thank you for your patch. But I have a question on packaging endian independent RPMs. 

If software needs a large number of data files and the files are so enormous, writing a patch is not easy job. The patch makes software always use little endian, then how does it work on big endian architecture? Several kinds of secondary arch in Fedora are big endian. We do not give up compatibilities with them.

Here are summary of this bug's current status here:
This bug is discussing about how to deal with the binary model file, and about 3 solutions are posted here:
1. Consider zinnia-tomoe model data file arch-dependent, put the binary model in %{_libdir}, or %{_datadir} with the the arch name as the model file postfix.
2. Consider zinnia-tomoe model data file endian-dependent only, and provide both big-endian and little-endian model file.
3. Make a patch for zinnia, and make the model file completely arch-independent. (Thanks for Peng Huang's patch, sent to upstream.)

Personally I prefer the solution 1 from Dennis Gilmore, and copy his comment here:
>Reading though this it will be simpler for long term management for this to be
>architecture specific. rpm doesn't understand endianness and trying to shoehorn
>it in makes it much more complicated and difficult to work with.    

Please decide how to solve this problem, thanks in advance.

(In reply to comment #45)
> Here are summary of this bug's current status here:
> This bug is discussing about how to deal with the binary model file, and about
> 3 solutions are posted here:
> 1. Consider zinnia-tomoe model data file arch-dependent, put the binary model
> in %{_libdir}, or %{_datadir} with the the arch name as the model file postfix.
> 2. Consider zinnia-tomoe model data file endian-dependent only, and provide
> both big-endian and little-endian model file.
> 3. Make a patch for zinnia, and make the model file completely
> arch-independent. (Thanks for Peng Huang's patch, sent to upstream.)
> Personally I prefer the solution 1 from Dennis Gilmore, and copy his comment
> here:
> >Reading though this it will be simpler for long term management for this to be
> >architecture specific. rpm doesn't understand endianness and trying to shoehorn
> >it in makes it much more complicated and difficult to work with.    
> Please decide how to solve this problem, thanks in advance.    

I'd like to simply install small endian-specfic data into %{_datadir}, but without noarch for those package. For big endian-specific data, I suggest to split them into two noarch subpackages.

Tweak spec is much more eaiser than patching software to use arch-independent endian files or utilize endian-specfic data in %{_libdir}.

History show many packages install their endian-specfic data into %{_datadir}, but few packages install those data into %{_libdir} as I known.

e.g.
gcin: Input method for Traditional Chinese
scim-fcitx: FCITX Input Method Engine for SCIM
espeak: Software speech synthesizer (text-to-speech)

Notes:
Their are also some disscussion on debian's mail list. 
For espeak, the final decision is simply revoking noarch for espeak-data.
See http://packages.debian.org/sid/espeak-data

For sunpinyin(big data), the final decision is split endian-specfic data into two noarch subpackages.

If we decide to treak endian-specfic as arch-specfic, then a lot of packages in repo need patching. Also, it may waste space for end users, if we considring multilib circumstance. For F13, all primary arch is little endian now, splitting big endian-specfic data into noarch subpackage will also save space in fedora mirrors.

I cannot accept installing big endian-specific data into {_libdir}. Especially for sunpinyin, the shlib itself is small and arch-specific but requires some big data(>20MB), I cannot imagine to download those files twice for x86_64 users if someone wants to install both 32bit and 64bit libs.

I agree with Chen Lei, although Fedora has dropped ppc/ppc64 primary arch support.

Addtionally, I think that adding a meta package for connecting to endian-specific packages is a better choice. 

For example:

zinnia-tomoe is a meta package. If it is in big-endian arch, It depends on zinnia-tomoe-eb. If it is in little-endian arch, it depends on zinnia-tomoe-el. It is much more convenient for packagers who need to pack something depending on zinnia-tomoe.

Peng Huang's patch has been merged into upstream svn.
And now the model file is arch-independent.

And I opened a new bug to require update zinnia version to 0.06, See:
Bug 592808 - Please update zinnia to version 0.06.

After update zinnia to 0.06, then we can make zinnia-tomoe noarch.

I find that this package is not need now.

We already have handwriting-ja.xml and handwriting-zh_CN.xml in fedora and can be used to generate model files.

See http://koji.fedoraproject.org/koji/rpminfo?rpmID=1442023

Probably we still need a package to include zinnia format data files converted from tomoe. It could be a new package zinnia-tomoe or in zinnia self.

(In reply to comment #51)
> Probably we still need a package to include zinnia format data files converted
> from tomoe. It could be a new package zinnia-tomoe or in zinnia self.    

I think we can merge those data to zinnia or ibus-handwrite as a subpackage.

zinnia-tomoe is now a sub-package of zinnia, which automatically generated from tomoe xml.
Will close this bug soon.

zinnia-0.06-4.fc13 has been submitted as an update for Fedora 13.
http://admin.fedoraproject.org/updates/zinnia-0.06-4.fc13

zinnia-0.06-4.fc13 has been pushed to the Fedora 13 stable repository.  If problems still persist, please make note of it in this bug report.

zinnia-0.06-6.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/zinnia-0.06-6.fc12

zinnia-0.06-8.fc12 has been submitted as an update for Fedora 12.
http://admin.fedoraproject.org/updates/zinnia-0.06-8.fc12

zinnia-0.06-8.fc12 has been pushed to the Fedora 12 stable repository.  If problems still persist, please make note of it in this bug report.