On Sun, 2020-02-02 at 22:44 +0100, Arrigo Marchiori wrote: > Hello Frank, > > On Thu, Jan 30, 2020 at 10:57:09PM +1100, Frank Crawford wrote: > > > On Thu, 2020-01-30 at 11:40 +0100, Arrigo Marchiori wrote: > [...] > > > Maybe you could find a solution by using the --remote- > > > schema parameter? > [...] > > No, the use of "--remote-schema" is the issue as it passes data between > > the two programs in a specific format that has changed between python2 > > and python3 because of internal variations. > > I may have not explained myself correctly, or I might not have > understood anything at all. I'll try again :-) > > For what I understood: the "--remote-schema" is the template for a > command that is popen()-ed. > > If your server _and client_ have two executables for rdiff-backup, say: > A) ~/rdiff-backup-old/rdiff-backup > B) ~/rdiff-backup-new/rdiff-backup > > What is the problem in having the client calling: > > 1) ~/rdiff-backup-old/rdiff-backup --remote-schema 'ssh -C %s > ~/rdiff-backup-old/rdiff-backup --server' > > or: > > 2) ~/rdiff-backup-new/rdiff-backup --remote-schema 'ssh -C %s > ~/rdiff-backup-new/rdiff-backup --server' > > The old version on the client would call the old version on the > server, and the new version on the client would call the new version > on the server. > > What ``Old'' and ``new'' are, can be chosen with total freedom: stable > and beta? Python 2 and Python 3? Script and self-contained binary? > They would be completely independent, because the only common part > would be ssh transmitting their data. > > This still requires to have the same versions of rdiff-backup on the > client and servers, but does not require an upgrade, in terms of the > new version _substituting_ the old. They could coexist side by side! > > I hope I could explain myself more clearly now.
Ahh, yes, much clearer, and yes something along that line would work. It is just a scripting exercise of some form to get it working. > Regards, Regards Frank
