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#THEUSRHIERARCHYhttp://www.pathname.com/fhs/pub/fhs-2.3.html#USRLIBLIBRARIESFORPROGRAMMINGA…http://www.pathname.com/fhs/pub/fhs-2.3.html#VARLIBVARIABLESTATEINFORMATION
Thanks
Ian
