0

we operate within a corporate environment with many slightly weird constraints, to become effective in this environment we have created our own system for building and deploying software. The software typically works like this:

  1. Download and build and install the software to the temporary location $BUILD_ROOT/install.

  2. If all software packages is succesfully installed in step 1, "atomically" copy $BUILD_ROOT/install to $PREFIX using rsync.

This works quite well, but the problem is that some of the files created during the initial install step are not fully relocatable - and will contain contain the path $BUILD_ROOT/install.

I wondered if it were possible to make the $BUILD_ROOT/install directory (temporarily) appear as $PREFIX - i.e. that I could do something like:

  1. mount-trick $PREFIX $BUILD_ROOT/install
  2. configure and install software using $PREFIX - but due to the mount-trick the files will actually go to $BUILD_ROOT/install.
  3. cancel mount-trick
  4. rsync $BUILD_ROOT/install $PREFIX

I sort of feel something like should be possible using things like bind mount, loop mount and/or chroot?

user422005
  • 133
  • 1
  • 4
  • 3
    I think a better fix would be to store the target path instead of the build path... Is your build system entirely in-house, or is it based on something else? Most build systems can distinguish between build paths and installation paths (e.g. autoconf’s --prefix and DESTDIR). – Stephen Kitt Feb 27 '18 at 10:43
  • This seems to be similar to what the OpenBSD port building system does, using a "fake install directory" before creating the package (which is later installed by pkg_add). I don't know much about the internals of that though. – Kusalananda Feb 27 '18 at 10:49
  • Our build system is based on whatever native the package uses; i.e. configure+make, cmake, python setup, ... Have not (so far) had 100% succes with DESTDIR – user422005 Feb 27 '18 at 11:33
  • I’m not saying this means it’s easy, but Linux distributions manage to have 100% success, sometimes with patches admittedly. I do think it could be more useful in the long run to spend time getting build/install processes to work, than to spend time on a workaround. Each to his/her own though ;-). – Stephen Kitt Feb 27 '18 at 17:53

0 Answers0