Hi Simon, On 1/1/26 00:57, Simon Josefsson wrote:
However, how to handle this situation where a NEW package takes over the name of an existing package? Is that a good idea?
As long as the version of the *binary* package is higher than the one currently built by gnulib, this should just work.
Should we make an upload of 'gnulib' that drops the binary package, let that migrate to testing, and then upload git-merge-changelog to NEW?
I would do it the other way around, once you upload the new source to unstable, hold off uploading 'gnulib' without that binary until the new binary is in testing.
Will that cause any problems wrt package naming in the future?
Do you have any specific worries?
We could also use completely different package names for the new package, like 'git-changelog-merge' but I'm not sure this really solves anything: they would need to Conflicts: until the old gnulib package disappears, and then the naming would just be confusing.
If it is really the same binary, but built from a different source, then I don't think this is a great idea.
Boyuan Yang <[email protected]> writes:Please pay special attention to the *binary* package version. We may have to add an epoch on initial packaging. (do we need to discuss it on debian-devel?)
git-merge-changelog currently in unstable has version 20251215-1. The version of the new upstream source in the ITP was 1.0. What version do you intend to use for the binary?
Paul
OpenPGP_signature.asc
Description: OpenPGP digital signature
