Hi again,

I did some more thorough testing now. It turned out I was partly
comparing trees that had been "touched" by booting already. I generally
build with something along the lines of

    cd /usr/src
    ./build -d -r -m ${arch} -D /usr/netbsd-${arch} -O /usr/obj \
            -T /usr/tools

then archiving the result without any further modification:

    cd /usr/netbsd-${arch}
    tar pcvf ${tarball} .

Now I unpacked the virgin usr/share subtrees from each tar and used the
amiga tree as a reference for comparison.

    mtree -c -k flags,gid,mode,nlink,size,link,uid,ripemd160digest

Comparing the output with all the other trees gives the following
results now (actual checksums omitted):

i386:
usr/share/misc/vgrindefs.db changed
usr/share/misc/termcap.db changed
./usr/share/keymaps/amiga/din.map missing
./usr/share/keymaps/amiga/es.map missing
./usr/share/keymaps/amiga/fr.map missing
./usr/share/keymaps/amiga/pl_din.map missing
./usr/share/keymaps/amiga/pl_us.map missing
./usr/share/keymaps/amiga/sw.map missing
./usr/share/keymaps/amiga/us.map missing

I won't complain about the inconsistent output now ;)

Endianness makes a difference for .db files as pointed out by Luke
Mewburn. As db(3) is supposed to deal with the "other" endianness just
fine, I think I can map these out of the problem scope mentally.

sgimips:
./usr/share/keymaps/amiga/din.map missing
./usr/share/keymaps/amiga/es.map missing
./usr/share/keymaps/amiga/fr.map missing
./usr/share/keymaps/amiga/pl_din.map missing
./usr/share/keymaps/amiga/pl_us.map missing
./usr/share/keymaps/amiga/sw.map missing
./usr/share/keymaps/amiga/us.map missing

It seems we get a quite consistent output for archs with same
endianness/bit count (amiga and sgimips).

alpha:
usr/share/locale/ja_JP.ISO2022-JP/LC_CTYPE changed
usr/share/locale/ja_JP.ISO2022-JP2/LC_CTYPE changed
usr/share/locale/ja_JP.SJIS/LC_CTYPE changed
usr/share/locale/ja_JP.ct/LC_CTYPE changed
usr/share/locale/ja_JP.eucJP/LC_CTYPE changed
usr/share/locale/ko_KR.eucKR/LC_CTYPE changed
usr/share/locale/zh_CN.eucCN/LC_CTYPE changed
usr/share/locale/zh_TW.Big5/LC_CTYPE changed
usr/share/man/whatis.db changed
usr/share/misc/magic.mgc changed
usr/share/misc/magic.mime.mgc changed
usr/share/misc/vgrindefs.db changed
usr/share/misc/termcap.db changed
./usr/share/keymaps/amiga/din.map missing
./usr/share/keymaps/amiga/es.map missing
./usr/share/keymaps/amiga/fr.map missing
./usr/share/keymaps/amiga/pl_din.map missing
./usr/share/keymaps/amiga/pl_us.map missing
./usr/share/keymaps/amiga/sw.map missing
./usr/share/keymaps/amiga/us.map missing

It's strange, however, that the locales now only differ for the only
64bit arch in the group where before there was a difference between i386
and sgimips as well. I dont think they were modified during
booting/system usage before. I should have written down all my earlier
steps from building to comparing.

Takuya SHIOZAKI wrote:
> These have some "padding" fields.  They are indeterminate because
> they are not initialized by mklocale.  This is no problem to work
> because they are just padding and unused, although this is ugly.

> I fix the illness just now.  Thanks for your indication.

Thank you for the explanation and the quick fix.

Strangely, whatis.db also differs only for alpha now but it's not really
a problem given the functionality of interoperability is in place.

I was told that *.mgc files are really just "memory dumps" of tables to
avoid re-parsing of the associated plain text files at each invocation.
Are these a problem for a shared /usr/share with both 32bit and 64bit
machines? I could just go ahead and try it but I think it's better to
stay theoretical as sometimes there's more than "oh, it obviously works".

Luke Mewburn wrote:
> These [amiga keymaps] could probably be always installed, but I haven't
> looked at the ramifications of doing this however.

Are you going to? Apart from the lack of insight regarding the build
process I have no clue what the effects of always installing these could be.

A final question: can /usr/share be safely mounted read-only?

Thanks and regards,

Nino