On Mon, Apr 20, 2020 at 6:55 PM Frank Crawford <fr...@crawford.emu.id.au> wrote:
> Lance, > > Just to add a bit more on some of Kevin's comments, this does not break > any of your backups and existing backups are both readable and writable > with both versions. What is broken is the backup process in some cases, as > a Python3 master cannot talk to a Python2 slave, and visa-versa. > Thanks for that clarification! That's kind of what I assumed based on what you said. > It would not be as simple as having both installed, as you also need to > select which version you are attempting to talk to on the remote machine, > and the default configuration assumes that the name is the same on the > remote machine, although this is changeable, if you know the full command > syntax. > Noted > I will probably make a special version of rdiff-backup v1.2.8 that can be > parallel installed available on COPR, but it won't be part of EPEL, as, for > example EPEL-8 will only have rdiff-backup v2. I'm just in discussion with > packagers for other distributions to get some common naming for such a > package, and it is generally agree that we need the latest version to be > rdiff-backup. > Sounds good and that makes sense as well. > Also, it is only on a master server, i.e. one invoking remote backups, > that you would need have two versions, and some method of selection which > one you want to run based on the slave's version. This could be as simple > as two separate backup jobs or a much more complicate script. > > Regards > Frank > > On Mon, 2020-04-20 at 09:59 -0700, Lance Albertson wrote: > > What does the upgrade path look like from if folks are currently creating > backups using 1.x and they suddenly switch to 2.x? Is there an upgrade > path? Is there a way in EPEL to allow for both versions to exist to ease > migration? i.e. maybe by creating rdiff-backup2 which > supercedes rdiff-backup. > > Ideally, it would be nice to have some kind of an upgrade path so we don't > end up breaking all of our backups. > > I went ahead and added 'rdiff-backup-2*' to our excludes to be safe until we're ready for the upgrade globally. Thanks for all the hard work! I'm looking forward to getting all of our systems upgraded. > Thanks- > > On Mon, Apr 20, 2020 at 6:33 AM Frank Crawford <fr...@crawford.emu.id.au> > wrote: > > We have pushed into testing and intend to eventually release a new version > of rdiff-backup which has a significant incompatibly with the current > distributed version, when used in client-server mode. > > The current version is v1.2.8 and written in Python2, while the new > version is v2.0.0 and written in Python3, and the language change breaks > client-server mode, due to incompatible data representations between > Python2 and Python3. In all other respects the two versions are compatible > including the ability to read and write existing backup repositories. > > It should be noted that the v1.2.8 was released over 11 years ago and > while a small number of bug fixes have been added by the community, there > has been no co-ordinated work for a number of years, and no further > development will occur on the Python2 version. All future work, > enhancements and bugfixes, including security bugfixes, will be to the > Python3 version. > > If it is necessary to stay with the Python2 version, it is recommended > that you exclude rdiff-backup from future updates. > > Also, if you are testing the Python3 update in EPEL-7 (and EPEL-8) some of > the dependencies (python3-pyxattr and py3libacl) are also in the testing > repositories. > > If you have any questions about the update, please contact me. > > Frank Crawford > FAS: frankcrawford > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > > _______________________________________________ > > epel-devel mailing list -- > > epel-devel@lists.fedoraproject.org > > > To unsubscribe send an email to > > epel-devel-le...@lists.fedoraproject.org > > > Fedora Code of Conduct: > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > > > List Guidelines: > > https://fedoraproject.org/wiki/Mailing_list_guidelines > > > List Archives: > > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > > > _______________________________________________ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org > -- Lance Albertson Director Oregon State University | Open Source Lab
_______________________________________________ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
