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/
