On Sat, 2019-10-12 at 09:29:18 +0200, Ansgar wrote: > Guillem Jover writes: > > 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? > > Because sourceful uploads need a new source package.
That's kind of tautological no? :) Why does it need to be a sourceful upload? I'm probably missing something obvious, but when I checked yesterday the linux-signed-* source was just packaging bits, generated from the templates in the linux source, which I'm assuming do not change (except for its changelog) when a binNMU is triggered for the linux package? And then matching the type of upload of its parent source seems would make the most sense here? > > This is using the version suffix > > for binNMUs, using this convention for something that is not a binNMU > > seems just wrong. > > That's why I wrote the following: > > >> >> 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. > > (I don't care about using ".b1" instead of "+b1".) Ok, let me clarify the way I see this report. I have to agree using «.bN» would still seem wrong to me, as that's just working around the underlaying problem when reacting to a binNMU from the parent package with something in the child package which is a binNMU but not really. The combination of the binNMU versioning being used and the sourceful uploads is undefined behavior, and as such dpkg-dev fails in an undefined way. Should dpkg-dev fail more consistently and in a better way? Sure, but that still does not get rid of the problem that the versioning used here 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. > > So using "+b1" should be supported? > > > 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. :/ > > So using "+b1" should not be supported? > > I reported the bug because dpkg seems undecided if it should support > "+b1" or not. Whatever it decides, it should probably be consistent > between differnt parts of itself. It supportes +bN alright, as long as it is used for cases it was designed for. :) So for this bug, as I mentioned above, I guess I might end up making the +bN heuristic Debian-vendor specific, and apply it consistently, as I assume that if I removed the heuristic that would interpreted literally, as the case presented being fine. But ideally the heuristic should not be needed at all. My point is thar regardless of dpkg keeping and extending the heuristic or completely getting rid of it, the usage you present, w/ or w/o mangling seems still wrong? Thanks, Guillem
