This message is a follow-on from previous post "Where do people mount their external storage?" to discuss a method to overcome my problems outlined in that post.

I have started thinking about the need for anything in /usr on the flash filesystem. There seems to be little point to differentiate /bin and /usr/bin, for example, on the built-in flash. Why not just put everything in /bin, /sbin, /lib and ignore /usr altogether for the internal flash filesystem?

One way to do this would be to have ipk files built to install everything in /usr (i.e. if the package is selected as <M> in the config). That way any software loaded onto the "image" can go onto another storage device. I do understand that the flash root filesystem is built from ipk files in the first place so it is not necessarily as simple as I have stated it.

To add some technical substance to what I'm proposing, I'm considering adding a make variable PKG_PREFIX which is set in include/pakage.mk based on whether the package is built as "y" or "m". Package makefiles are then modified to use $(1)$(PKG_PREFIX) as the installation root. I would not want to change the Package/foo/install $(1) parameter to include this so that packages can still put their config files in $(1)/etc. The bulk of the files would go into $(1)$(PKG_PREFIX), but a packager can choose to ignore $(PKG_PREFIX) if necessary.

The actual value used for PKG_PREFIX for modules could be a configuration parameter, so people could use /usr/local or elsewhere if they wanted to.

[Is this the best forum for discussing development ideas like this? The mailing list looks rather quiet.]

Slight change to the PKG_PREFIX idea. Instead of defining PKG_PREFIX (which has problems due to nesting of $(eval $(call ...)) and needing to use $$(PKG_PREFIX), or maybe $$$$(PKG_PREFIX)), a second argument is supplied to Package/foo/install which contains the installation prefix.

An installation macro would look like:

define Package/foo/install
  $(INSTALL_DIR) $(1)($2)/bin
  $(INSTALL_BIN) $(PKG_BUILD_DIR)/foo $(1)$(2)/bin
  $(INSTALL_DATA) $(PKG_BUILD_DIR)/foo.conf $(1)/etc
endef

Treat the external drive as an overlay and you won't run into these issues.

If you really insist on our idea I'll point out ipkg aleady lets you assign a prefix, avoiding the need for custom packages.

So, it's a bad idea either way.

I had considered this but I couldn't see how to handle the case where some files should be overlayed onto the jffs partition if changed (such as /usr/lib/*.awk, /usr/share/udhcpc/default.script) because they may be needed to boot the system or get it to a point where /usr could be mounted, and when the files should be overlayed onto the external partition.

I gather this prefix applies to all files in the package? So if you used a prefix of /opt for instance, you'd end up with files in /opt/etc, /opt/usr/bin, etc? That's rather messy, but doable.

Apart from the validity of my method of achieving this, do you see a particular reason for maintaining a distinction between / and /usr ? I'm asking because on embedded systems I've developed, I've done away with /usr without any issues, because the rationale for /usr (according to FHS) doesn't make much sense in the embedded devices that I've targetted.