I would oppose this change.
On Wed, Jun 13, 2018 at 11:13:27PM +0200, Paul Gevers wrote:
> I second the diff below.
>
> Paul
>
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 0771346..166cdd8 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -552,9 +552,10 @@ The three components here are:
> omitted, in which case zero is assumed. If it is omitted then the
> ``upstream_version`` may not contain any colons.
>
> - It is provided to allow mistakes in the version numbers of older
> - versions of a package, and also a package's previous version
> - numbering schemes, to be left behind.
> + Epochs can help when the upstream version numbering scheme
> + changes, but they must be used with care. You should not change
> + the epoch, even in experimental, without getting consensus on
> + debian-devel first.
There is no harm in an epoch. It's a part of the version number. Yes, it
is a part that cannot be lost, but it does not cause any harm to the
distribution if they are used incorrectly. The same is not true for
preinst scripts; when those are overused, packages may end up not being
installable anymore, which does actively cause harm.
Documenting why you should not use epochs in certain cases does make
sense, but I think we should trust our developers to understand what
they're being told, rather than requiring people uselessly email -devel
(and clutter that mailinglist, which also causes harm).
> ``upstream_version``
> This is the main part of the version number. It is usually the
> @@ -622,9 +623,23 @@ These two steps (comparing and removing initial
> non-digit strings and
> initial digit strings) are repeated until a difference is found or both
> strings are exhausted.
>
> -Note that the purpose of epochs is to allow us to leave behind mistakes
> -in version numbering, and to cope with situations where the version
> -numbering scheme changes. It is *not* intended to cope with version
> +Epochs should be used sparingly
> +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> +
> +Note that the purpose of epochs is to cope with situations where the
> +upstream version numbering scheme changes and to allow us to leave
> +behind serious mistakes.
This makes sense.
> +If you think that increasing the epoch is the right solution,
> +you should consult debian-devel and get consensus before doing so
> +(even in experimental).
This, I think, should be removed.
> +Epochs should not be used when a package needs to be rolled back.
> +In that case, use the ``+really`` convention: for example, if you
> +uploaded ``2.3-3`` and now you need to go backwards to upstream 2.2,
> +call your reverting upload something like ``2.3+really2.2-1``.
> +Eventually, when we upload upstream 2.4, the +really part can go away.
> +
> +Epochs are also not intended to cope with version
> numbers containing strings of letters which the package management
> system cannot interpret (such as ``ALPHA`` or ``pre-``), or with silly
> orderings. [#]_
These make sense, too.
We could add another paragraph saying what the downsides of epochs are,
and why they should be avoided.
But requiring a consensus on -devel seems like wasting people's time to
me.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
