Hi martin-Eric, On Tue, Jul 11, 2023 at 06:30:38PM +0300, Martin-Éric Racine wrote: > On Mon, Jul 10, 2023 at 7:30 PM Martin-Éric Racine > <martin-eric.rac...@iki.fi> wrote: > > > > On Mon, Jul 10, 2023 at 7:05 PM Salvatore Bonaccorso <car...@debian.org> > > wrote: > > > 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. > > > > Agreed. > > > > > > 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? > > > > In Trixie, for the version, it would. Just insert the epoch for the > > whole source (which would apply to the binaries generated too) and > > we're done. > > > > However, we still need that preinst script to clean up possible Wheezy > > leftovers. > > > > In Bookworm, we'll still need the version mingle just for one binary > > target. debdiff for stable-proposed-updates are on #1037190 and the > > upload is ready on Mentors. > > > > > 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 > > > > I was actually wondering how to close those old CVE against the old fork. > > > > > > Or have I misunderstood the issue? > > > > > > No, I think we are on the same page in my understnding! > > > > Excellent. > > Reintroducing the epoch produces the following Lintian ERROR: > > E: dhcpcd source: > epoch-changed-but-upstream-version-did-not-go-backwards 10.0.1-2 -> > 1:10.0.1-3 [debian/changelog:1]
The lintian tag in it's intention is clear. But I believe in this case it reports in error. Because the history of the dhcpcd source package is as follows, cutting of some irrelevant inbetween steps: 0.4-1 -> 1.3.8-0.1 -> 1:0.70-5 (epoch introduced here), then moved upwards -> 1:3.2.3-11 / 1:3.2.3-11+deb7u1 which was the last version available for a while. But then we dropped to 10.0.1-1 (which already missed the epoch). Now the lintian just only checks 10.0.1-2 -> 1:10.0.1-3 and thinks to report that the epoch addition is an error, but it would not if all the 10.0.1-1, 10.0.1-2 versions already had the epoch still. Does this make sense? Regards, Salvatore
