Not sure if that helps much. These scripts aren't executing necessarily
on Debian, so we can't rely on the dpkg comparison mechanism. Is
there anything to be gained by ripping out the logic within dpkg?
And speaking from experience, I can state that the GPLed comparison
mechanism now in place in revisions-lib.inc works for almost everything
we've seen. About the only place we've seen it trip up is comparing
version strings like "1.2.3" vs "1.2.3 alpha", where 1.2.3 is actually
the latest version. This it will not catch, and needs to be coded
as an exception manually.
But for everything else, revcomp() will give return values like
strcmp(), but will handle numeric comparisons as true numerics,
even when imbedded in a string:
revcomp("10", "9") => Returns 1 (10 > 9)
revcomp("1.2", "1.2-2") => Returns -1 (1.2 < 1.2-2)
revcomp("v23.a3", "v23.a10") => Returns -1 (v23.a3 < v23.a10)
revcomp("Apache/1.37.3", "Apache/1.37.4") Returns 1
This gets rid of the endless stream of bugs that used to be seen
in nasl scripts as a result of poor regex handling of version numbers
that go from single to double digits, and makes it easy on the
developers, since version numbers don't have to always be parsed
out, if the prefixes of the strings being compared are the same.
If you know of a circumstance where the existing mechanism doesn't
do what it is supposed to (and could reasonably be expected to handle
it), let me know and we'll make the improvements necessary.
Thomas
Tim Brown wrote:
> It might be worth investigating Debian's own version comparison
> mechanism:
>
> dpkg --compare-versions "$2" lt "1.4.3-18"
>
> Tim
_______________________________________________
Openvas-devel mailing list
[email protected]
http://lists.wald.intevation.org/mailman/listinfo/openvas-devel
