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
