Control: tags 1029085 + wontfix Control: close 1029085 Hi Scott,
On Tue, Jan 17, 2023 at 02:52:49PM +0000, Scott Kitterman wrote: > It's not policy compliant, which may be okay in this instance, but it > certainly isn't ideal. I looked into this and figured that indeed the Debian Policy has a section 6 on this matter. Interestingly, this policy says little about how compatible programs actaully need to be. It merely states that packages need to cooperate. It also mentions vim vs nvi as an example. If you've ever used either and then gotten onto a system that selected the other or even just vim-tiny, you notice significant differences in their usage and abilities. To me, the differences between borg 1.x and borg 2.x are similar, so I consider the vi example a supporting argument for using alternatives. I happen to had to look into whether update-alternatives are appropriate as part of the CTTE decision on the rename implementation. There, the CTTE ruled that they should not use update-alternatives, because you couldn't actually use them in a compatible way. This does not apply to the borg transition where a number of invocations continue to work. > Here's another approach: Let me call this the python approach, because python pioneered it with python-is-python2 and python-is-python3. From a user point of view, this practically is an implementation detail with three differences to update-alternatives: * You may choose not to have the unversioned instance (by not installing a *-is-* package). * You can depend on the unversioned instance being a particular version using a package dependency. * The incantation for changing the unversioned instance is a different command. Other than this, little changes from a user's point of view. So is any of these differences relevant here? I think lacking an unversioned instance is not an important feature. The difference in incantation is not something I care about either. However, being able to depend on a particular version is something I didn't really consider in sufficient depth thus far. Indeed, borg does have reverse dependencies: * backupninja * borgmatic * fbx-all * freedombox * vorta * And maybe some ITPs for other frontends as well. Moving forward with my update-alternatives plan could mean breaking any of these. For instance, * backupninja uses borg init https://sources.debian.org/src/backupninja/1.2.1-1/handlers/borg.in/#L129 * borgmatic adapts to the borg version dynamically and can handle either * fbx-all is a metapackage and happens to Recommend borgbackup among other things * freedombox uses borg init https://sources.debian.org/src/freedombox/23.2/plinth/modules/backups/privileged.py/?hl=183#L119 * vorta uses borg init https://sources.debian.org/src/vorta/0.8.9-1/src/vorta/borg/init.py/#L31 My update-alternatives approach would break three of them, so that's a big argument against using update-alternatives. The python approach has a different downside. > Borg 1 gets a new binary, borg-is-borg1 that provides usr/bin/borg symlinked > to borg1. The existing package depends on it for Bookworm, so it's > guaranteed to be installed. If borg depends on borg-is-borg1, then of course you cannot coinstall borg 1.x with borg-is-borg2. I'm not sure whether this is relevant. In any case, we can simplify the matter here by making borgbackup Provides: borg-is-borg1 and do away with one package. We can actually do away with the whole borg -> borg1 rename dance as you can never have borg1 installed without borg being borg1. So, we can just skip this entirely. That laves borgbackup2 shipping borg2 and borg-is-borg2 shipping symlinks and Conflicts: borgbackup. The benefit here is that installing borg-is-borg2 will kick all of the reverse dependencies. borgmatic should update its own to borg-is-borg2 | borgbackup. So thank you for your persistence on this. The fact that update-alternatives do break rdeps is a really convincing argument, that only came across relatively implicitly. Helmut