On Thu, 15 Feb 2018 at 11:09:08 +0100, Wouter Verhelst wrote:
> I was thinking it might be better to go to a "wildcard" epoch:
>
> Depends: X (>= *:1.8)
>
> would mean
>
> "For this comparison, ignore the epoch, and make sure that the version
> is at least 1.8 or above".
This would work for the "oops, that was meant to go to experimental"
case where +really also gets used, but would do the wrong thing for the
original purpose of epochs, which is dealing with upstream version
numbering that doesn't match dpkg semantics.
For instance, if your upstream uses a date-based version number (20180215
or 18.01 or something) but later decides that they don't like that
version scheme and switches to 1.0, 1.1, ..., adding an epoch is the
only way to make such versions sort correctly (if you have predicted
this situation ahead of time, you can use versions like 0~20180215, but
epochs are precisely for the situation where you weren't able to predict
how upstream's version numbering would change). Helpful upstreams don't
do this, but not all upstreams are helpful, so general-purpose packaging
systems like dpkg and rpm need an "escape hatch" to cope.
We don't have to look far to find a weird versioning scheme that can't
be represented without epochs: our largest competitor in the field of
general-purpose operating systems has such a versioning scheme. Imagine
we had a package that followed the same versioning scheme as Windows (I
could imagine a parallel universe in which Wine used the version number
of the version of Windows that it claims to emulate). If we packaged
that, using the "marketing version" wherever it's numeric or making up
something reasonable wherever it isn't, we might have had a versioning
scheme like this:
3.1
3.11
95
98
2000
1:5.1+XP # or 2001+XP or something
1:5.2+Vista # or 2006+Vista or something
1:7
1:8
1:8.1
1:10
Ignoring the epoch would be actively harmful here: if you have a versioned
dependency on Windows >= 8, it would be incorrect for Windows 95 to
satisfy that dependency.
smcv
