Hi, Alexander Moisseev wrote on 2017-03-13 20:45:49 +0300 [Re: [BackupPC-devel] IPv6 support?]: > On 3/13/17 7:23 PM, Fritz Elfert wrote: > > [...] > > Instead, make a second package "backuppc4". This way, user can have > > both versions installed and then gracefully migrate. > > You can't use both v3 and v4 on the same host as they install files in the > same place.
that wouldn't need to be true, since distribution packages can choose where to install which file (and which files possibly to share). However, I can't really see much point in running both versions on one host aside from brief testing for migration, and distinct paths for both versions would considerably complicate migration, somewhat negating the whole point. The distribution would be left "forever" with somewhat unnatural paths (e.g. /etc/backuppc4, /var/lib/backuppc4, /usr/share/backuppc4 ...). I would rephrase your comment as "it shouldn't be possible to install distribution packages for both v3 and v4 on the same host" ;-). > However, keeping v3 package "backuppc" and making "backuppc4" package for v4 > is a quite good point as a lot of people use v3 in production and changes > between v3 and v4 are substantial. I fully agree with that. Version 4 is a whole new philosophy, with which you may or may not agree. It's a bit like "upgrading" from init to systemd. No offence intended ;-). > BTW v3 support is not dropped by upstream yet. Another good point. It's a bit awkward to release packages for new v3 releases that supercede older v3 packages but not older v4 packages if the package name is identical :-). Les Mikesell wrote on 2017-03-13 13:14:21 -0500 [Re: [BackupPC-devel] IPv6 support?]: > My opinion is that nothing should ever break in a 'yum update' from > CentOS/EPEL repositories if it can possibly be avoided. And even > with v4 in release status there may be reasons to install v3 or > rebuild a machine without changing anything. I also agree with that (and would extend it to other distros). > Using different package names will let them co-exist for at least as long > as v3 will be maintained and let the sysadmin decide when to switch. > I might think differently if the upgrade could be completely transparent, > though. I don't see how a transparent upgrade would make the reasons go away, for which you might want to install v3 or decide when to switch. (*) While running v3 and v4 on the same host does not sound like a good idea, running them on *different* hosts definitely does! Regards, Holger (*) Aside from that, it is not *possible* to guarantee a transparent upgrade. My RsyncClientCmd might invoke a remote end that is dependent on the exact sequence of arguments passed by File::RsyncP, so upgrading might even involve changing and recompiling code on a remote machine. The normal cases (ssh, sudo, ssh + sudo) might work, but the flexibility the configuration mechanism gives you comes at the cost of not being able to predict what people will actually do. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ BackupPC-devel mailing list BackupPC-devel@lists.sourceforge.net List: https://lists.sourceforge.net/lists/listinfo/backuppc-devel Wiki: http://backuppc.wiki.sourceforge.net Project: http://backuppc.sourceforge.net/