second argument

[treinen]

An idea for the second argument of the maintainer scripts:

one place where these are used is when the arguments of the maintainer script are passed on to dpkg-maintscript-helper. Dpkg-maintscript helper then checks whether the version passed as second argument to the script is <= than the version pased as prior-version to dpkg-maintscript helper.

So what one could do is go over the CST of the scripts of the package and identify all prior-version arguments of dpkg-maintscript-helper (these are expected at different positions that depend on the sub-command to dpkg-maintscript-helper) and use these as possible second arguments to the maintainer script. This would IMO allow to execute the different code paths of dpkg-maintscript-helper.

[Niols]

That is indeed a good idea, to crawl through the script to guess interesting versions. We should also probably find all the uses of dpkg --compare-versions. An other way that is less complete but probably gives some results would be to use a minimum and a maximum versions. But they don't exist, right? I guess we can just take a really low (with ~?) and a really high version (with a really high epoch?)

[treinen]

Right, we also have to look at dpkg --compare-version.

The order on debian versions is dense without endpoints. However, it is trivial to construct from a given version one that is strictly smaller (by adding "~" at the end") and one that is strictly larger (by adding something not starting on "~" at the end)

[Niols]

Are we sure that we can find these versions statically? Or do we need to start with a random version and gather a list of comparisons we have made so that we can produce other versions that should be executed? (A bit like concolic execution).

This doesn't make much sens though. But since versions are not very complicated objects, could we maybe handle them symbolically? I mean, we already have a symbolic engine, so…

— Nicolas Jeannerod

Le 24 juin 2019 02:39:09 GMT-07:00, Ralf Treinen notifications@github.com a écrit :

Right, we also have to look at dpkg --compare-version.

The order on debian versions is dense without endpoints. However, it is trivial to construct from a given version one that is strictly smaller (by adding "~" at the end") and one that is strictly larger (by adding something not starting on "~" at the end)

[treinen]

I cannot imagine that anyone does computations on version numbers. On the other hand there are some varieble setting to take into considerations, like sometimes scripts do something like LASTVERSION=$2 and then call dpkg --compare-versions on $LASTVERSION.

So I would expect that just taking all constant arguments of dpkg --compare-versions would work in a majority of cases.