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
Ian Lynagh wrote:
[...] 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 can only second Ian here, having an architecture-dependent PATH / library path is archaic, IMHO. Even automounters a decade ago could handle this more elegantly, at least if the admin in question cares to read the man pages. :-] There are tons of programs which would have to handle this compared to a single automounter/whatever config. So let's make this our mantra: "/usr is write-only and /usr/lib is /usr/lib!" Cheers, S.
Ian Lynagh
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
participants (3)
-
Ian Lynagh -
Malcolm Wallace -
Sven Panne