Re: Version Woes

[Frank Crawford]

On Thu, 2020-04-23 at 14:16 -0400, Derek Atkins wrote:
> Frank Crawford <
> address@hidden
> > writes:
> 
> > Okay, when I get the rdiff-backup 2.0 out in the various
> > Fedora/EPEL
> > repos, including the optional packages for pylibacl and pyxattr for
> > EPEL8, I'll see if I can knock up a version of rdiff-backup 1.2.8
> > on
> > my COPR repo.
> > 
> > If there is a big enough demand I will look at how I can get a
> > rdiff-
> > backup 1.2.8 build into EPEL8, but the real intention is to move
> > forward with version 2 and onwards.
> 
> Unless and until we have a way for "current" version to talk to
> "ancient" version, we will necessarily need to maintain 1.2.8 for the
> foreseeable future.

Understand that, which is why we are looking at some options.

> 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.

> 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.

> 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.

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.

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.

Regards
Frank