[nhc-users] /usr/lib/hmake/$arch-$os/

[Malcolm Wallace]

Ian Lynagh <igloo at earth.li> writes:

> 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.

I think there is some misunderstanding here.  By default, hmake does
not place any files under /usr/lib.  It uses /usr/local/lib.  According
to the FHS docs you reference, this is the correct behaviour.  /usr/lib
should be read-only, and contain only system files.  /usr/local/lib is
for system adminstrators to install extra non-system software.

Furthermore, according to the FHS, your suggestion to place
/usr/local/lib/hmake/`harch`/hmakerc instead under /var is not
correct either.  /var is for 'variable' files, but the system-wide
hmakerc file is static.

> 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.

OK, so the right thing to do here is to fix the `harch` script to
amalgamate s390 and s390x into a single string, like it already does
for i[3456]86 which all convert to "ix86".

> 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).

Not everyone uses debian of course, so this is not a portable solution.

> 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.

Again, we should be talking about /usr/local/lib rather than /usr/lib.
To quote from the FHS:

    The /usr/local hierarchy is for use by the system administrator
    when installing software locally. It needs to be safe from being
    overwritten when the system software is updated. It may be used
    for programs and data that are shareable amongst a group of hosts,
    but not found in /usr.

So I think it is reasonable to have multiple architectures
distinguished here where necessary.

> relevant links:
> http://www.pathname.com/fhs/pub/fhs-2.3.html#THEUSRHIERARCHY

Regards,
    Malcolm