Dear all,
  we have had some trouble trying to install both the i386 and x86_64 
flavours of libgcj-3.4.6-8 on SL4. Unless this is done at (Kickstart) 
install time, RPM reports file-level conflicts for the man pages in this 
case:

...
   file /usr/share/man/man1/fastjar.1.gz from install of libgcj-3.4.6-8 
conflicts with file from package libgcj-3.4.6-8
...

The reason for this appears to be (both RPMs rotten multilib 
implementation and) the fact that the man pages are not identical 
between i386 and x86_64, so that the 
"these-files-are-the-same-so-we-can-silently-ignore-the-conflict" RPM 
logic doesn't kick in:

$ rpm -qa --queryformat '%{NAME}-%{VERSION}-%{RELEASE}.%{ARCH}:\n[ 
%{FILENAMES}\t %{FILEMD5S}\n]\n' libgcj | grep 
'^lib\|/usr/share/man/man1/fastjar.1.gz'
libgcj-3.4.6-8.i386:
   /usr/share/man/man1/fastjar.1.gz       631cf1102cf16d285f6d36b45e8fffe8
libgcj-3.4.6-8.x86_64:
   /usr/share/man/man1/fastjar.1.gz       7448711dd9efa98ff8ac7709df6b7a4a

Whereas on a "real" TUV4.5 machine, we get
libgcj-3.4.6-8.i386:
   /usr/share/man/man1/fastjar.1.gz       20048e9160b185a6d3b1b6bf2df90949
libgcj-3.4.6-8.x86_64:
   /usr/share/man/man1/fastjar.1.gz       20048e9160b185a6d3b1b6bf2df90949


The difference between these files on SLC4 is
< .TH JAR 1 "2007-05-03" "gcc-3.4.6" "GNU"
---
 > .TH JAR 1 "2007-05-07" "gcc-3.4.6" "GNU"

i.e. they got rebuilt on a different day, and unfortunately decided to 
record the fact in the man page.

Similarly, fontconfig-2.2.3-7.{i386,x86_64} has in 
usr/share/man/man5/fonts-conf.5.gz:

< .TH "FONTS-CONF" "5" "17 February 2005" "" ""
---
 > .TH "FONTS-CONF" "5" "14 March 2005" "" ""

TUV in both cases has the same file/date - presumably they got rebuild 
on the same day.


Would it perhaps be possible to rebuild these two packages? - I guess 
they will cause trouble for others in the future as well...


fontconfig-2.2.3-7:
< /usr/share/man/man5/fonts-conf.5.gz    1d94a3481d2ee2894cead03cf82a02e6
---
> /usr/share/man/man5/fonts-conf.5.gz    c895dcf301435cdb0f8ab38de027f87a

libgcj-3.4.6-8:
< /usr/share/man/man1/fastjar.1.gz       631cf1102cf16d285f6d36b45e8fffe8
< /usr/share/man/man1/gij.1.gz   bef80782f78e4385e3eb9cd89432e563
< /usr/share/man/man1/grepjar.1.gz       4e98e29086af1a753c6cddf5bbf47462
< /usr/share/man/man1/grmic.1.gz         2bc72c4ef345ea42778f6e7aae82ae3f
< /usr/share/man/man1/grmiregistry.1.gz  5fc12c7c062aef2ba079f78982f15d14
< /usr/share/man/man1/jv-convert.1.gz    cafb9362ce42ef95a39f4aeb34dc2875
---
> /usr/share/man/man1/fastjar.1.gz       7448711dd9efa98ff8ac7709df6b7a4a
> /usr/share/man/man1/gij.1.gz   d4a0193bff8c5a71e8b72b66b554617d
> /usr/share/man/man1/grepjar.1.gz       b1cc08d598a3f75ebc3196bdcf584c83
> /usr/share/man/man1/grmic.1.gz         d68d2326078935a9497989fdd2b924ee
> /usr/share/man/man1/grmiregistry.1.gz  77159807060980a1923b68479ff2479e
> /usr/share/man/man1/jv-convert.1.gz    833630556953aa6c17d304214eab1db8



TIA
Jan


PS: red herring ahead:

Such differences can also be due to the fact that "compressed" files 
carry a timestamp by default, unless some care is taken to avoid this. 
http://www.redhat.com/magazine/009jul05/features/multilib/ has some more 
insights into this:

> If the 32-bit package is built just one second later than the 64-bit package,
 > the timestamp in the compressed file will be different in each package.

Which is why rpm-build's "brp-compress" script uses
COMPRESS="gzip -9 -n"
since the early days of SLC41..