"Dr. Tobias Quathamer" <[email protected]> writes: >> I have a mild preference for letting golang-*-dev track latest upstream >> version because I think that matches how non-Go versioned libraries are >> usually maintained in Debian, but I'm happy to trade that preference for >> your approach if we can get team consensus to write it down in policy. > > For me, the main argument *against* tracking the latest upstream version > is that you'd always need to fix all reverse dependencies and do a > mini-transition -- whereas you can just upload the new upstream version > with a new package name and suffix without breaking anything.
Right. The current lestraat-jwx migration was a bit painful because we staged patches in Salsa that could only be uploaded after NEW processing, which took months, so the staged patches had to be reverted or moved to a separate branch to permit uploads of other packages for other updates while NEW processing took place. Still, I think the final result for lwstraat-jwx will be nice. It is just that temporarily things are ugly. > This implies that every new major version of a module would most > probably need all reverse dependencies patched to be usable. That is not my experience -- many packages continue to build fine with later versions even though they pin to some earlier ABI version. I'd say this may even be the norm, unless upstream REALLY breaks all of the ABI in massive ways. Often only some marginal/obsolete API is modified or removed. So how can we update modify to resolve this concern? /Simon
signature.asc
Description: PGP signature
