Hi Dennis, On 14-08-2022 13:32, Dennis Filder wrote:
If I make a new version 4.4.13-4 for unstable, it will then contain the very changes that led to the creation of 5.0.37-2 for experimental (thus rendering it redundant), and the latter will also not have 4.4.13-4 as a predecessor in its changelog.
That's OK, because it really didn't have that version as predecessor.
In a nutshell, shouldn't any new upload to unstable automatically nuke any newer version already in experimental as otherwise it becomes impossible for the experimental package to migrate to unstable without introducing changelog inconsistencies in the form of missing entries?
No. The changelog of any version in Debian is supposed to contain the information of how that version came about. Having said that, it is important (in case of bugs being filed or closed in versions that aren't mentioned in the future) that the right "Closes: #xxx" stanza's get mentioned somewhere in *both* changelogs where the bug is fixed.
I presume to handle this correctly that I'd have to do something like rebase all 5.0.37-* releases onto 4.4.13-4
No, if that's not how you history looked like, you don't need to fake it like that. (Although, it's also OK to do it if it makes sense to you).
, then create 5.0.37-3 with no changes except its changelog rewritten to explain which changes were backported to unstable and which releases were obviated as a result.
If all you do in unstable is fixing a bug that's already fixed in experimental, experimental doesn't need any changes. And if the version in unstable remains lower than the version in experimental, it will remain there without action.
Is there an established way to express this?
Not that I'm aware of, because you don't need to. Paul
OpenPGP_signature
Description: OpenPGP digital signature
