Hi Antoine,
>Both as a user and developer of borg backup, I disagree with some of >the comments made of borg in this bug report. wonderful :) (I really like when somebody disagree/complains, it usually they care and want to have better tools) >Borg has actually shown great API stability since it forked from >Attic. The change that occured was necessary, and was well documented >in the release notes and the manual. (It should have been documented >in the NEWS.Debian file in the Debian package as well.) It is also the >*only* one that happened in over 15 releases since the fork from >Attic. We can even still convert older, prehistoric attic repositories >to borg without data loss. ack on this >Furthermore, this only concerns the backup remote RPC protocol. The >storage format is *still* compatible, all the way back to attic. If >you have a copy of your repository, you can still backup to and from >it. If your server is upgraded, it is true that you do need to upgrade >your client, however (and vice-versa). sure >But tons of backup software in Debian have that behavior: unison was >already mentionned, but rdiff-backup also has the same problems. That >is why we have backports: when the server side upgrades, we upgrade >the clients to the backports version. It's annoying, but it works, and >rdiff-backup has been in Debian for a long time. Those other backup >softwares are way more popular, sometimes by orders of magnitude, than >borg: > >https://qa.debian.org/popcon.php?package=rdiff-backup >https://qa.debian.org/popcon.php?package=unison >https://qa.debian.org/popcon.php?package=borgbackup true >Keeping borg from entering stable (or, more precisely, testing in this >case) is exactly what we *don't* want here. If we keep borg from >entering testing, we keep it from being backported. If we keep it from >being backported, we make it *harder* for people to run the same >version of borg across different versions of Debian. So we basically >make the Debian package useless, which means people won't use it and >will instead use the pip version. note: borgbackup *is* in testing right now. the autoremoval won't happen before of 25 of this month and IIRC commenting on this bug will delay the autoremoval. >Is that what we want? I'm not sure about this :) >I was looking at backporting borg from stretch to jessie, but if the >maintainers are going to remove it from stretch, i'm certainly not >going to bother, and that would be a shame... I hope it will be part of stretch, sure. >Finally, keep in mind that this is a problem only in Debian, and only >if we have multiple, incompatible versions of borg in >Debian. (Non-debian installs can use virtualenvs to install as many >borg versions as they want.) Right now, we only have one version >(0.29.0-2), and it's compatible between unstable and testing. If >testing gets released right now, stable, testing and unstable are all >compatible, and we have absolutely no problem. > >Furthermore, it's very likely that borg 1.0 gets released before >stretch, so all those arguments will be completely irrelevant because >borg *will* be API stable. this would fix the issue once for all >This, in short, is a non-isse right now. If 0.28 was in stable and >0.29 in testing, this would be a bug, but then the fix would be a >backport, not a removal from stable (which you can do, if you are >really stuck, anyways). > >Now, can i open this bug about backporting? :) nope. Backport has been asked so long time ago, and I have personally backported one reverse dependency in jessie-backports (setuptools-scm https://packages.qa.debian.org/s/setuptools-scm.html ) but when I asked zigo about python-msgpack he told me "I'll backport it soon" and in fact I remember seeing the package in jessie-backports new queue. For some obscure reasons the package got rejected, and I'm still investigating about this. You can ask all the backports you want, but for sure we need to have the build dependencies prior to do them. BTW a little bit off-topic, but the package 0.29 will be in xenial (unless you provide 1.0 in the next month or so). While I can agree about backporting stuff in Debian, this usually will become a trouble in debian-based distros, where usually nobody actively maintain leaf packages (well, I'm a recent MOTU Ubuntu Developer, so I'll probably be able to backport it). I don't want, neither Debian wants to break Derivative distros just because of API changes. So please, don't talk about this issue like a Debian specific one, it affect also other distros too. I agree about what Danny said, we can downgrade this bug, but it will happen on Ubuntu/Mint/Whatever if we don't fix it in some way. Thanks for the clarification, I think we have ~20 days to downgrade it, and probably it will be downgraded. Even if we don't downgrade it in 20 days, it will migrate as soon as we do it, so really not an issue (except for people who won't be able to install the package of course). This bug is the sign that we really care about borg userbase, not the opposite, and I'm pretty sure we will make a even better package after this discussion (and some debian/NEWS files :p ) (at the end, I'll fully trust Danny's opinion to downgrade this bug if appropriate) cheers! Gianfranco
