Re: Version Woes

[Derek Atkins]

Frank Crawford <address@hidden> 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
       address@hidden             www.ihtfp.com
       Computer and Internet Security Consultant