allow install overwrite

Issue #57 resolved
Dan Bonachea created an issue

Currently if a user installs to a directory already containing a UPCXX install (eg to update it) they usually get the following error;

rm -Rf .nobs/ ; env GASNET=/home/pcp1/bonachea/UPC/inst-ex DBGSYM=1 OPTLEV=0 ./install --single test9   
...
*** Something FAILED! ***
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Installation aborted because it would clobber files in "/home/pcp1/bonachea/UPC/upcxx/test9"
UPC++ Installation failed. Please report the entire log above to: upcxx@googlegroups.com

If that directory happens to be dedicated to a upcxx install (the usage model we should probably recommend), this is just a nuisance and the fix is simply to rm -Rf the target directory and try again.

However, if the install directory is actually a tree containing other software (eg /usr/local) then the user has no simple solution and is effectively stuck. We don't provide a nobs uninstall to remove our software, or a means to overwrite the old installation.

So in the case of a dedicated install tree, the prohibition against overwriting the old install is essentially a pointless nuisance, and in the case of a shared install tree it's actively harmful.

This is the reason why automake installs overwrite existing files in the target directory by default. We should provide a similar option for the same reason, and possibly make it the default because it makes more sense and is what most admins expect.

Concerns about file name collisions are (already) addressed by ensuring that all files being installed either use a project-specific name prefix (eg $prefix/bin/upcxx-meta) or go into a project-specific directory (ie $prefix/include/upcxx/*.hpp).

It's also worth noting the current "don't overwrite" behavior does not even provide proper "abort" semantics - if it discovers a conflict halfway through installation then it aborts without unwinding, leaving half an install in the target directory.

Comments (3)

  1. Former user Account Deleted

    I will change the behavior to implicit overwrite.

    The reason for the existing behavor was to be very conservative about the installer never issuing any destructive updates. The installer will happily overwrite if the source files match byte-for-byte with the destination (ie the overwrite is a no-op). I was trying to push destructive actions on to the user (rm -rf upcxx_install).

    Rollback semantics on abort are in place, but they have a bug and its easier to switch to the always-overwrite policy advocated by Dan and autoconf.

  2. Log in to comment