On Thu, 2019-10-10 at 09:44:21 +0200, Ansgar wrote: > Guillem Jover writes: > > On Thu, 2019-10-10 at 08:15:07 +0200, Ansgar wrote: > >> With the first binNMU the changelog used 5.2.17+1+b1 as the version > >> and this caused disagreement between different parts of dpkg. > >> dpkg-source generates linux-signed-amd64_5.2.17+1+b1.dsc, but > >> dpkg-genchanges strips the trailing +b1 from the version: > [...] > >> I'll suggest to work around this by mangling the version a bit more > >> and use .b1 instead of +b1, but the disagreement seems to be a bug in > >> dpkg. > > > > It looks to me that the problem might actually be the missing > > binary-only=yes key/value in the changelog header though, which the > > original should have? Could you check whether that would completely > > fix this? > > It should generate a new *source* package, it is not binary-only. > dpkg-source does do so.
Why should it generate a new source? This is using the version suffix for binNMUs, using this convention for something that is not a binNMU seems just wrong. > But dpkg-genchanges seems to (still) use the heuristic stripping the +bX > from versions instead of using the binary-only key (which is not present > here). > > I think either: > > - dpkg-source should refuse to generate source packages using > binNMU version numbers (that trigger the heuristic that other parts > of dpkg use), or This would still point at a problem with the version used. I'd rather stop using the heuristic because we have metadata for this, and they are Debian-centric things. But if the alernative is to allow packages that break the versioning convention for no apparent good reason, then I guess I might need to move this as a vendor-specific logic, and apply it everywhere. :/ > - dpkg-genchanges should be able to generate changes files for source > packages that use versions ending in +bX (provided no binary-only is > set); i.e. stop using heuristics and instead rely on the binary-only > key. Same as the previous point. Thanks, Guillem
