mjhjmtu

I have a follow-up question after https://unix.stackexchange.com/a/435293/674

Suppose I have a personal configuration or startup file in my backup external hard drive or github repository, for example, .profile (or any other configuration or startup file).

Suppose that I switch to a new Ubuntu system temporarily or permanently. The new OS has a default ~/.profile.

When deploying my backup file to the new system, is it necessary to merge my backup one and the default one manually, or can I just overwrite the new system's default one with my backup one?

I am not sure if overwriting is a good idea, because the default parts in the configuration files in the previous system and the new system might be different.

Is there some best practice to make the deployment simpler and easier?

For example, I was wondering if it is a good idea that my backup file contains only those commands which I have added manually, and when I deploy it to a new system, I just prepend my backup file with the content of the new system's default file, and replace the new system's default file with a symlink to the newly modified backup file.

Thanks.

When deploying my backup file to the new system, is it necessary to
merge my backup one and the default one manually, or can I just
overwrite the new system's default one with my backup one?

Is it necessary? Technically, no. Practically, yes. Indeed, more than just merging must be considered in the general case, as you might find some of the commands from your old file to be wrong enough for the new that they just need to be removed.

I am not sure if overwriting is a good idea, because the default parts
in the configuration files in the previous system and the new system
might be different.

There are two general categories of commands you generally find in environment setup files:

• settings related to configuring software and features available on the host, and


• 
  shell environment customizations

The latter can be transferred more or less safely, as the only likely gotchas would be things arising from incompatibilities between shell versions. Those are rarely an issue in practice. The former, however, may not make sense to transfer at all.

It is mostly harmless to set environment variables that no installed software will use or to add path elements that don't actually exist, but you may lose access to available software if you clobber relevant contents of your default shell startup files. Or if you've performed deeper customizations, then you may find that they rely on software that isn't provided by the new system, or that they don't work as desired with the new machine's software.

Is there some best practice to make the deployment simpler and easier?

Yes. Systems should avoid relying on per-user shell startup files, or at least avoid putting in any settings of the first kind described above. There are good and well-tested mechanisms for configuring users' environments that do not require per-user files to be set up or managed. Ideally, then, systems won't provide non-empty per-user shell startup files at all.

Users, for their part, could consider keeping shell environment customizations well separated from configuration of specific tools and applications, preferably in separate files. Ideally, little or none of the latter is needed, and what you do need would be best modularized.

For example, I was wondering if it is a good idea that my backup file
contains only those commands which I have added manually, and when I
deploy it to a new system, I just prepend my backup file with the
content of the new system's default file, and replace the new system's
default file with a symlink to the newly modified backup file.

If you want to keep the default file (if any) separate from your additions, then a better bet would be to keep your additions in an altogether different file, such as ~/.profile-Tim, and modify the default file only by appending a command to read those commands, i.e.

test -r ~/.profile-Tim && . ~/.profile-Tim

Do not, then, backup or transfer ~/.profile, but update it anew as necessary to source your customizations.

Even so, however, you can run into trouble, as it is possible for personal software configuration settings you move over to be incorrect for your new environment. You can make this easier to manage by keeping your customizations well modularized, but it is in the nature of customizations to have some degree of specificity to the base system.