#740 PR merged: Rename RECOVERY_FS_ROOT into TARGET_FS_ROOT

Labels: cleanup, fixed / solved / done

jsmeix opened issue at 2015-12-15 11:43:

Rename RECOVERY_FS_ROOT into TARGET_FS_ROOT to describe what it actually is.

The former name RECOVERY_FS_ROOT (see https://github.com/rear/rear/issues/708) is misleading.
In the "recover" workflow it is not the root of the filesystem tree of the recovery system
but it is the root of the filesystem tree of the to-be-recovered system
i.e. it is the root of the filesystem tree of the target system of the "recover" workflow.
Furthermore the former name RECOVERY_FS_ROOT is incomprehensible in future workflows
like the "install" workflow (see https://github.com/rear/rear/issues/732)
where the root of the filesystem tree of the to-be-installed system
would have to be called INSTALL_FS_ROOT to have a meaningful name.
Therefore the name TARGET_FS_ROOT is now used because
it describes what it actually is independent of the workflow.

schlomo commented at 2015-12-15 13:04:

Did you consider RESCUE_FS_ROOT? It comes to my mind since it is actually only relevant for the mkrescue part of ReaR.

jsmeix commented at 2015-12-15 13:25:

@schlomo
in the current sources no file of the "mkrescue" workflow
contains 'RECOVERY_FS_ROOT' or 'mnt/local'

# for f in $( rear -s mkrescue | grep '^Source ' | sed -e 's/^Source /\/usr\/share\/rear\//' ) ; do egrep -H '_FS_ROOT|mnt/local' $f ; done
[no output]

therefore I do not understand how it is relevant at all
for the mkrescue part of ReaR.

Perhaps you got already confused by the misleading "RECOVERY"
in 'RECOVERY_FS_ROOT'?

schlomo commented at 2015-12-15 13:27:

@jsmeix good point - I stand corrected.

+1 for meaningful rename :-)


[Export of Github issue for rear/rear.]