cabal-install: v2-install should touch symlink target

[frasertweedale]

Describe the bug
When running v2-install using symlink method (the default), cabal will not rebuild if the package+hash is already in the cabal store, it does not rebuild the package. Instead it just (re)writes the symlink to point to the exist binary. This is what we want.

The problem is that programs in the environment may use stat to query program modification time, for audit or other behavioural reasons. For example, if the modification timestamp of the symlink target did not move forward in time, programs that use dyre or similar techniques will not be able to notice that the executable changed.

To better support such use cases, v2-install should touch (update modification timestamp) the target executable, ensuring that observers will always see it as changed/newer.

Please use version-prefixed commands (e.g. v2-build or v1-build) to avoid ambiguity.

Additional context

In some cases it is possible for tools to work around this issue by:

• inquiring whether the file in question is symlink
• if so, check the modification time of both the symlink (lstat) and its target (stat).

But if doing this from within the Haskell process (e.g. when using dyre or similar techniques),
getExecutablePath gives you the actual executable file, not the symlink that was resolved to it (if any).
Using getProgName is less reliable and imposes yet more burden on the application. It can all
be avoided by simply touching the target executable when writing the symlink.

Alternatively, we can change nothing and expect the user who runs v2-install to also touch the symlink
target themselves. If we are concerned that touching the executable could have unintended consequences
for other use cases, then we could at least add something to the documentation to explain that cabal intentionally
leaves the executable as-is, and use cases that need the modification timestamp to be bumped must deal
with that manually.

[jneira]

hi, thanks for the proposal and detailed analysis
One not too complex workaround in the call site could be do a cabal install foo --install-dir /bar && touch /bar/foo, no?

As you commented it is not sure that touch would be the expected behaviour so at least a flag should be added and I am not sure if the complexity added given the mentioned workaround

[frasertweedale]

@jneira indeed, an explicit touch following the cabal install invocation suffices. It is a bit annoying and can be confusing as to why an "install" command can result in the target executable having an earlier timestamp than what was previously pointed to.

This situation can catch you out in a development scenario where you jump back and forward between branches.

It's hard to know who or what might break by changing the behaviour to always touch the target executable. A config/flag to control the behaviour would be an acceptable solution.

[Mikolaj]

I can imagine a user that copies the generated executable only if it changed to save bandwidth, which would be ruined if we touched the exe every time.

If the solution naturally factors into "install" and "touch", perhaps it should be performed by the user as the two steps? Perhaps we could make it easier for the user to do so. E.g., does touch $(cabal list-bin exe) or something like that (is there a bash command to dereference links?) work fine? If not, we might focus on improving this to give the user better orthogonal tools instead of random amalgams. If yes, we might document this use case in the cabal manual.