Control: reopen -1 Hi Martin-Eric,
On Sun, Jul 09, 2023 at 10:39:59PM +0300, Martin-Éric Racine wrote: > On Sun, Jul 9, 2023 at 10:33 PM Salvatore Bonaccorso <car...@debian.org> > wrote: > > On Sun, Jul 09, 2023 at 09:25:33PM +0200, Salvatore Bonaccorso wrote: > > > Source: dhcpcd > > > Version: 10.0.1-1 > > > Severity: serious > > > Justification: Debian version goes backwards from previous released > > > versions > > > X-Debbugs-Cc: car...@debian.org > > > > > > Hi > > > > > > The new src:dhcpcd has a lower version of any previous released > > > src:dhcpd version, which had an epoch: > > > > Apologies for the typo, should be src:dhcpcd in both cases obviously > > :( > > Which is a slightly different issue than what Andtreas reported at > #1037190. Sorry. No problem, just reopenng while we discuss it. > Unless I'm mistaken, we're basically looking at 2 separate issues: > > 1) bin:dhcpcd from Wheezy has a higher epoch that the one in Bookworm. > This is easily fixed as explained in #1037190 for Bookworm. > > 2) Since transiting the source from src:dhcpcd5 to src:dhcpcd we're > missing an epoch for everything. This requires reverting the above fix > and simply introducing an epoch for the whole src and binaries. Yes correct, this is maninly as well what I was referring to. But that would solve as well at same time the former issue right, if we drop all special casing for epoch on the binary packages, is this correct? So if we add the epoch to the whole src;dhcpcd version, and to the produced binaries I think all the issues should be resolved. My background is here: https://security-tracker.debian.org/tracker/source-package/dhcpcd e.g. https://security-tracker.debian.org/tracker/CVE-2002-1403 will be considered not yet fixed, because for dpkg: $ dpkg --compare-versions 1:1.3.22pl2-2 lt 10.0.1-1 $ echo $? 1 > Or have I misunderstood the issue? No, I tink we are on the same page in my understnding! Thank you for looking into this issue. Regards, Salvatore
