Frank Crawford <fr...@crawford.emu.id.au> writes:
>> Sometimes you just can't upgrade a system but you still need to be
>> able
>> to back it up. I've got one server still running Fedora 20!
>
> However, a different way to address it would be to export the backup
> repository via something like NFS and then just running the 1.2.8
> locally on the Fedora 20 server.
>
> It is only the communication that is the problem, not the actual backup
> repository.
That presumes that the old server is talking to the repo, but that's not
necessarily how it works. In my case it is:
[NFS] --- [Backup Server] -- [Servers being Backed up]
I can generally control the version on the Backup Server. I cannot
always control the version on the Servers being Backed up. However, it
would be nice if there were some way to auto-detect the other end and
then fork/exec/switch to a compatible wire protocol.
>> Lack of cross-version support is going to be a MAJOR issue for a
>> while!
>> The client-server incompatibility will require maintaining both
>> versions, at least in one place in a deployed backup solution.
>
> However, they need to have different names, hence, as it stands you
> cannot install both packages at once.
I don't understand. Why can't they be called rdiff-backup and rdiff-backup1?
>> To that end, I recommend we try VERY HARD to have both 1.2.8 AND
>> 2.current available as packages in distros (the same way you can have
>> both python2 and python3 simultaneously).
>
> You talk about Fedora 20, but if you stay on the Fedora builds, python2
> no longer supported, and shortly won't even be available.
Are you sure? Fedora-32, just released today, still has Python 2.
> As well, if we try and put a python2 version into a distribution we
> would also expect to provide at least patches for security issues, if
> they occur. Especially for long-lived distributions like RHEL7 &
> RHEL8.
Sure, but 1.2.8 has been in that sitation for half a decade now. What's
changed today vs a year ago (beyond having rdiff-backup-2 now)?
> The easiest way out of that is to ensure that there is no implied
> support, i.e. by making something available, but outside the normal
> distribution.
>
> This is why I am looking at supplying something out of COPR, but even
> that brings in issue with dependencies, such as pylibacl and pyxattr,
> which I also need to look at how to make available.
There is a question of support, and there is a question of backwards
compatibility. In my mind the latter is more important. I don't expect
(and frankly don't want to make) changes to "old" systems. But I'd like
"new" systems to continue to be able to talk to them.
> Regards
> Frank
-derek
--
Derek Atkins 617-623-3745
de...@ihtfp.com www.ihtfp.com
Computer and Internet Security Consultant
