Subject: Re: /usr/share differs between archs
To: None <>
From: Luke Mewburn <>
List: tech-userlevel
Date: 05/12/2003 12:50:47
On Sun, May 11, 2003 at 01:19:06PM +0200, Nino Dehne wrote:
  | Hi list,
  | currently I'm playing around with different archs (namely alpha, amiga, 
  | i386, sgimips) and NetBSD. I could crossbuild amiga and sgimips on the 
  | i386 (thank $DEITY!). Poor 21066 is still building his own world since 2 
  | days, though. All machines are diskless as far as NetBSD is concerned.
  | Anyway, looking at the completed builds I got reminded about some 
  | principles of BSD's file structure, i.e. /usr/share/ ought to be 
  | shareable among different machines, hence the name. Making up about 53M 
  | each it also occupies a quite large portion of a whole build (130-150M) 
  | so i could gain about 150M by keeping it on the server only once. 
  | hier(7) seems to be with me:
  |      /usr/      contains the majority of the system utilities and files
  |                 [...]
  |                 share/    architecture-independent text files
  | A quick mtree(1) check between i386's and sgimips' /usr/share/ reveals 
  | checksum differences in the following files:
  | locale/ja_JP.ISO2022-JP/LC_CTYPE
  | locale/ja_JP.ISO2022-JP2/LC_CTYPE
  | locale/ja_JP.SJIS/LC_CTYPE
  | locale/ja_JP.ct/LC_CTYPE
  | locale/ja_JP.eucJP/LC_CTYPE
  | locale/ko_KR.eucKR/LC_CTYPE
  | locale/zh_CN.eucCN/LC_CTYPE
  | locale/zh_TW.Big5/LC_CTYPE

I don't know why these are different.

  | man/whatis.db
  | misc/vgrindefs.db
  | misc/termcap.db

That's because db(3) files have an endianness, which defaults to the
appropriate endian of the target platform.  db(3) does support
automatically reading files of the "other" endianness though.

  | I consider these minor because I a) don't use them or b) they look like 
  | like the probability to get 2 identical files is slim (while not being a 
  | sophisticated approach to look at it, I actually think it has to do with 
  | the way .db files are built). As to why the locales differ: no clue.

Yes, see above.

  | Then I checked the amiga build and noticed that i386 and sgimips are 
  | lacking the contents of keymaps/amiga/. Alpha build still isn't finished 
  | so I couldn't check that yet.

These could probably be always installed, but I haven't looked at the
ramifications of doing this however.

  | While it surely makes sense to leave out amiga keymaps on i386 or 
  | anything != amiga this would have prevented me from using the keymaps 
  | had I just gone ahead sharing the i386's /usr/share/ to all machines 
  | without actually double checking the contents. Right now I concluded I 
  | just take the amiga /usr/share/ (being a superset of the others) and 
  | share it to the rest.
  | Shouldn't /usr/share/, by its nature to be machine-independant and 
  | shareable, contain everything for every architecture? This may seem like 
  | a small issues but it bothers me nonetheless. I haven't dug into the 
  | build process too deep yet, either so I can't submit patches or 
  | anything. That's why I'm asking/pointing out first.

Yup, /usr/share should be (NFS) sharable amongst various MACHINEs.