Re: new mailx should have lower version number

[Ian Jackson <ian@chiark.chu.cam.ac.uk>]

Sven Rudolph writes ("new mailx should have lower version number"):
> I decided to go back to an older mailx version for Debian.
> 
> Now the problem is: How will dpkg find out that this lower version
> number should overwrite the higher one ?
> 
> Do you have any tricks on this ?

Oh dear.  No, I don't.  At the moment the only thing to do would be to
use a really higher version number, or install the new version
manually in some way.

All the solutions I can think of involve me making changes to dpkg.
I'd rather postpone these until after the beta release.

Here are the possibilities I can think of:

1. Bruce's date-based version scheme.  This has problems, because it
doesn't (if the versions are strictly dates) allow one to make a minor
update to the stable version of a package and still have it be counted
as older than the recently-released `unstable' version of the same
package.

2. Add some kind of control file field which lists version numbers
that are really older than this one.  This seems ugly, and won't allow
proper comparison of the version number everywhere.

3. Add an `epoch' to the version number, either as a separate control
file field, or as a prefix to the existing version number (I prefer
the latter, I think - prehaps [<epoch>:]<version>[-<revison>], since
colons don't seem to have been used in version numbers so far).  This
wouldn't necessarily be displayed by dpkg all the time, but would
allow you to `forget' about old version numbers by increasing the
epoch.

Comments on the merits of the proposals above, and additional
proposals, would be welcome.

Ian.