Re: Can unison better help with renamed hosts?

Greg, your opposition is based on the assumption that the hostname is
the one and only ID to be used. What I'm saying is that it doesn't
need to be that way. If you consider the proposal from this
perspective then (at least to me) all the opposing arguments fall
away.

On Wed, 24 Apr 2024 at 14:19, Greg Troxel <[email protected]> wrote:
>
> Letting people configure the server's hostname on the client does seems
> useful for testing and debugging, but it adds complexity and unison is
> already too complicated.

It doesn't add complexity other than yet another preference. The
override mechanism is already there (and useful enough not to be ever
removed).

> As I see it, the main path is that the server (remote root via ssh) asks
> the OS for "hostname" and uses it.  For systems with stable hostnames,
> this works fine, and I don't see a need to depart from this main path.

Agreed, my proposal was only as an optional override mechanism.

> Rather, I suggest that people who want to run unison on a host fix their
> unstable hostname problem, or set UNISONLOCALHOSTNAME.

This is not always so easy (especially if you don't have the deep
knowledge). The users shouldn't be forced to do it, but it will be an
option for those who want to/can do it.

> We have one override mechanism, UNISONLOCALHOSTNAME.  I think that to
> first order, the configuration for what name is used for a computer
> should be on that computer.   That means a config file that unison
> reads, more or less like the env var.

My proposal is not intended to _be_ the host name, it's intended to
_replace_ it. And the primary benefit it has over current mechanisms
is precisely that it is set on the client.

> Do we really have a problem that is not resolved by UNISONLOCALHOSTNAME,
> once understood?

In my mind, it's just very technically involved and the user shouldn't
be forced to go that route. You may argue that anyone using Unison is
already technically skilled enough, but it shouldn't be that way. It
also doesn't suit the permanent rename scenario well.

> I would lean to keeping hostname, because this is about overriding the
> gethostname(3) name.  Sure, it is arbitrary, but this all flows from
> "generally, each computer has a name" and everything else is fixups.

Hostname can be seen as a more or less arbitrary choice that was
easily at hand and worked good enough. Using an "instance id" in its
place is nothing weird, I think.

To unsubscribe from this group and stop receiving emails from it, send an email to [email protected].