Hello Ian,
On Fri, Feb 23 2018, Ian Jackson wrote:
> We had another thread on debian-devel recently, in which it once again
> became evident that epochs are misunderstood. Epoch bumps should be
> rare and there are often better solutions. I suggest that we should
> ask people to consult debian-devel.
I agree.
> Also we should encourage the +really convention rather than epoch
> bumps.
I agree.
> + Epochs can help when the upstream version numbering scheme
> + changes, but they must be used with care. In Debian, please
> + consult debian-devel when changing the epoch.
This doesn't use one of the usual Policy terms "must", "should" or
"recommended", yet it's an imperative, so I find it ambiguous whether
this is a requirement of Policy or a suggested best practice.
So I think we should have:
You should not change the epoch for a package before this has been
discussed on the debian-devel mailing list and a consensus about
doing that has been reached.
This is consistent with wording elsewhere in Policy.
I also prefer to drop the "In Debian" because Policy does not usually
qualify Debian-specific practices, and if we are going to start doing
that, we should have a separate discussion and not let it hold up this
bug.
> ...
>
> Note that the purpose of epochs is
> - to allow us to leave behind mistakes in version numbering, and
> to cope with situations where the
> + upstream
> version numbering scheme changes
> + and to allow us to leave behind serious mistakes
> .
> +
> + Epochs should not usually be used when
> + a package needs to be rolled back (use the +really convention)
I would prefer to see an explanation of the +really convention if you'd
care to write one, but that's informative so can be added later.
> + or to
> cope with
> - It is not intended to
> version numbers containing strings of letters which the package
> management system cannot interpret (such as ALPHA or pre-), or with
> silly orderings.
> +
> + If you think that increasing the epoch is the right situation,
> + please consult debian-devel before doing so
> + (even in experimental).
For consistency, s/please/you should/.
Seconds?
--
Sean Whitton
Attachment:
signature.asc
Description: PGP signature