Looks like the APT system recognizes the latest package version incorrectly:

root@254b2e798358:/vyos# dpkg --compare-versions 25.06.0-26~gf1cd717e4 lt 25.06.0-25~gff09d1749-dirty
root@254b2e798358:/vyos# echo $?
0
root@254b2e798358:/vyos# dpkg --compare-versions 25.06.0-26~gf1cd717e4 gt 25.06.0-25~gff09d1749-dirty
root@254b2e798358:/vyos# echo $?
1

However, it works correctly if we compare in the following way:

root@254b2e798358:/vyos# dpkg --compare-versions 25.06.0-26~gf1cd717e4 gt 25.06.0-25~gff09d1749
root@254b2e798358:/vyos# echo $?
0

Looks like that "-dirty" is considered as a part of the version value.

The version should follow the format: [epoch:]upstream_version[-debian_revision].

Allowed characters are as follows:

• epoch: A single (generally small) unsigned integer.
• upstream_version: Alphanumeric characters (A-Za-z0-9) and the characters ., +, -, :, ~ (full stop, plus, hyphen, colon, tilde). It should start with a digit. If there is no Debian revision, hyphens are not allowed. If there is no epoch, colons are not allowed.
• debian_revision: Alphanumeric characters and the characters +, ., ~ (plus, full stop, tilde).

Thus, -dirty in the end changes how the version is parsed.

1. 25.06.0-25~gff09d1749:
   • no epoch
   • upstream_version: 25.06.0
   • debian_revision: 25~gff09d1749
2. 25.06.0-25~gff09d1749-dirty:
   • no epoch
   • upstream_version: 25.06.0-25~gff09d1749
   • debian_revision: dirty
3. 25.06.0-26~gf1cd717e4
   • no epoch
   • upstream_version: 25.06.0
   • debian_revision: 26~gf1cd717e4

The package management system will break the version number apart at the last hyphen in the string (if there is one) to determine the upstream_version and debian_revision. The absence of a debian_revision is equivalent to a debian_revision of 0.

Comparison logic is:

Note (if I understand the manual): Debian splits versions into non-digit and digit-only parts, and then compares them left-to-right. Where:

• digit-only parts are compared mathematically. If one of the versions in comparison has no such part available, it is considered as 0.
• non-digit parts are compared lexically. An empty place (end of the string) is considered "older" than any character, except ~.

Therefore:

25.06.0-26~gf1cd717e4 vs. 25.06.0-25~gff09d1749: no epoch, upstream_version is the same. Comparing debian_revision left-to-right: first character that is different is 6 vs. 5 - 6 wins.
25.06.0-26~gf1cd717e4 vs. 25.06.0-25~gff09d1749-dirty: no epoch. Comparing upstream_version (25.06.0 vs. 25.06.0-25~gff09d1749): first character that is different is (actually nothing, but I do not know how to write this in Markdown, so let's pretend there is no space inside) vs. - - 25.06.0-25~gff09d1749 wins, because, < -, the end of the string is older than anything else, except ~.

For more details, refer to: Debian Policy Manual - Version.

However, the problem comprises two distinct issues:

1. The "dirty" issue described above, or more generally, our non-compliance with Debian versioning rules.
2. The fact that we sometimes update our patches for packages and rebuild them with the same upstream version without incrementing the version number. This can result in versions like 25.06.0-26~gf1cd717e4 and 25.06.0-26~gff09d1749, which differ only by commit IDs. Consequently, it becomes unpredictable which version will take precedence.

To fully resolve the problem, we need to address both issues.

PR https://github.com/vyos/vyos-vpp-patches/pull/23