On Wed, Oct 25, 2017 at 12:39:45AM +0200, Axel Burri wrote: > Here's a quick summary of the btrbk dependencies: > > all versions of btrbk >= 0.23.0 require btrfs-progs >= 3.18.2 > > btrbk-0.25.0 supports ALL versions of btrfs-progs <= 4.11.1 > btrbk-0.25.1 supports ALL versions of btrfs-progs <= 4.13.1 > btrbk-0.26.0 supports ALL versions of btrfs-progs >= 3.18.2 > > > > To prevent this, please provide a bpo of btrbk-0.25.1. > > Unfortunately I'm not a debian user myself and don't know much about all > this. If I understand it correctly, this is not needed now?
If you'd like to support all Debian users of btrbk, then it is needed, but if you don't want to maintain a backported package please let me know, so I can forward this info to debian-backports. Here is the rationale: Currently in stretch/stable: btrfs-progs-4.7.3-1 and btrbk-0.24.0-1 * no problems Currently in sid/unstable: btrfs-progs-4.13.3-1 and btrbk-0.26.0-1 * no problems Stretch user with btrfs-progs-4.9.1~bpo9+1 and btrbk-0.24.0-1 * no problems (I think) Stretch user who has btrfs-progs-4.9.1~bpo9+1, who receives automatic upgrade to btrfs-progs-4.13.3~bpo9+1, or who enables stretch-backports specifically to install a newer btrfs-progs (this is recommended by upstream btrfs devs, as I'm sure you know ;-) ) - has btrbk-0.24.0-1 - Dependency resolution does one of these, because "Breaks" was added to btrfs-progs: 1) blocks upgrade to btrfs-progs-4.13.3~bpo9+1 2) removes btrbk-0.24.0-1 (btrbk is uninstalled but not purged) 3) user forces upgrade, breaking dependency resolution and backups stop working. 4) installs btrbk-0.26.0-1~bpo9+1 * Apt will chose #4 as the optimal resolution 100% of the time if a bpo of btrbk is available. I believe #1 is its first choice if a bpo of btrbk is not available and #2 would be the second choice resolution offered by aptitude. Additionally, I think that apt will also put btrfs-progs-4.9.1~bpo9+1 into the "held state" if a bpo of btrbk is not available. If a backport of btrbk-0.26.0 is made, a user can use btrfs-progs-4.7.3-1 from stable with btrbk-0.26.0-1~bpo9+1. So there is always one reason (or three reasons, depending on how you count) why a backport is needed, and no reasons against. If you don't tag Debian releases then you can merge commit@point to a stretch-backports branch. I like to use tags, because then I don't have to remember which commit I uploaded to unstable. You can even script it. eg, after the stretch-backports branch is set up: #!/bin/sh git tag -l echo -n "what is the version in testing? " read testing_version git merge debian/$testing_version git mergetool dch --bpo # remove extra line that looks like " * " git add debian/changelog git commit echo -n "what is version in backports, or in stable if NEW" read bpo_version # copy and paste the tag you want gbp buildpackage --git-pbuilder \ --git-debian-branch=stretch-backports \ --git-dist=stretch-backports \ --git-tag \ -v${bpo_version} # I think the following will also work, but I haven't tested it # dpkg-buildpackage -v${bpo_version} # git clean -fd # head -1 debian/changelog # echo -n "what is the new version? " # read new_version # paste the version from first entry of changelog # new_version=$(echo $new_version | sed s:\~:_:) # git tag debian/$new_version Cheers, Nicholas
signature.asc
Description: PGP signature