Hi, hmake uses /usr/lib/hmake/$arch-$os/ to put various files in, but I've had a couple of issues with this. First, as /usr can be mounted read-only I've moved hmakerc to /var/lib/hmake/$arch-$os/hmakerc. I can filter out the bits of the diff that do this (with a --confdir argument to configure) if you are interested. Second, the $arch component as detected by harch can vary between machines using a single Debian arch, e.g. s390 and s390x both use s390. This of course means hmake can't find its files and so thinks it isn't installed. I imagine similar issues will face binary packagers of other distributions in time. I have two ways of fixing this. One is to make a replacement harch that just echos what "dpkg-architecture -qDEB_HOST_ARCH" says instead of what it would currently detect (although I don't have a good replacement for $os currently). The other is to just drop the $arch-$os/ path component completely; the FHS says (well, strongly implies at least) that /usr/lib is architecture-dependent anyway. I imagine the reason you put this in is that there are some systems where /usr/lib is shared between machines of different arches? However, would it not be simpler for the admins of those machines to just give --libdir accordingly? Presumably they already have to do so for other OS software anyway. I think the nicer solution for Debian is the latter, so the reason for my bringing it up is that it will make my life easier if you adopt it too :-) The other use of harch I've seen is per-arch/os .hmakerc files, which seems fine as it is to me. relevant links: http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGAN... http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION Thanks Ian