Erm, bind mounts?

Would it perhaps be better to handle pkg upgrades differently?
- add /upg-root/{bin,lib,etal} to PATH (earlier in PATH so old-pkg is used until new-pkg is ready for use)
- move old-pkg's files to /upg-root/...
- install new-pkg
- upgrade old-pkg's config/etc. files to /....
- clear /upg-root

The old pkg is moved aside, but still usable. The new pkg is installed, prepared and configured. The old pkg is erased. This would eliminate the cornfusion of which files are old and which are new, which are gnarled and which are true. And would work after pkgs are split.

I encountered related problems as I attempted to build an initramfs for a small distro I manage. I found that if I made /bin a symlink to /usr/bin, at least some pkgs would, for example, replace the /bin symlink with a real dir. I finally gave up, let stuff install where it wanted to, then moved everything from /{bin,lib,etal} to /usr/..., and replaced those dirs in / with symlinks to those in /usr. (Or maybe I moved stuff from /usr to /; don't remember now, but it's the same problem.)

Whilst I only have about 200 pkgs to handle, many of them make it easy to change install locations, but enough of them seem to obfuscate how to change where they install as to make it more of a bother than it's worth.

Debian's /{bin,lib,etal} scheme is workable, but may still cause problems when someone builds and installs a pkg only to discover that the pkg replaces the /bin and /lib symlinks with real dirs, and then spends hours figuring out what went wrong. (Not everyone is an experienced admin or developer. And even if they are, the process of creating a .deb from scratch is so poorly documented that most people will just give up and install directly.)