Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, 2018-06-28 at 14:34:06 +0200, Wouter Verhelst wrote:
> On Thu, Jun 28, 2018 at 01:43:17PM +0200, Guillem Jover wrote:
> > On Thu, 2018-06-28 at 13:03:56 +0200, Wouter Verhelst wrote:
> > > On Thu, Jun 28, 2018 at 11:39:53AM +0100, Ian Jackson wrote:
> > > > The requirement to consult d-d has worked very well with Pre-Depends.
> > > > Many pointless and harmful Pre-Depends have been avoided this way,
> > > > with very low levels of project-wide effort.
> > >
> > > Yes. There's a difference though.
> >
> > Sure, but not in their harmfulness, though. :)
>
> That's just a matter of opinion.
I don't think it is though. I'd even say bogus epochs bumps are
potentially more harmful than Pre-Depends! Pre-Depends are localized
in a single package, and their effects can be easily tested, but the
validity of the rationale for its introduction might be difficult or
impossible to check automatically, though. But the full effects of
epoch bumps are not easily testable at all and they are changes with
global effect, for all rdepends (in-archive and local), local forks,
etc.
From the categorization I did in the dpkg FAQ, there are two main
scenarios:
* valid bumps due to version schema change, where even though the
version-space gets reset, the releases have continuity.
* invalid bumps, either because they are completely unnecessary, or
because the releases break the continuity.
When breaking the release continuity, and forcing an invalidation of
all relationships, it means we might be breaking upgrade scenarios,
satisfiability checks, interface requirement checks, etc, this is a
silent and very harmful thing. As I mention on the FAQ the
relationships can be hidden in many places, not just in control
metadata, which makes checking for this way more difficult.
And just to be clear, epochs have their place, that's why they were
created. They might be somewhat ugly and confusing, but when used
correctly they are better than any other alternative, and any
ill-effects are unavoidable anyway. The problem is when those
ill-effects are caused by bogus usage of epochs.
> > > Incorrect pre-depends are actively harmful. They may cause dependency
> > > loops which dpkg cannot fix, and may therefore result in problems that
> > > go way beyond the package which introduced the incorrect pre-depends. In
> > > that context, I agree that trying to reach consensus on -devel before
> > > introducing a pre-depends is a good idea.
> > >
> > > Incorrect epochs are a nuisance at best. There's a myth going around
> > > that they cause a "stigma", which I suspect is where this comes from,
> > > but in actual fact they're just a few extra characters in a version
> > > number with some special semantics, and nothing beyond that.
> ^^^^^^^^^^^^^^^^^^^^^^
BTW something I missed in my previous reply, the fact that it might
(should! :) be considered a stigma is IMO a good thing, because it
might make people think at least twice before introducing them. :)
> > No, they are not just a decorator for the version, they have a
> > semantic meaning,
>
> I know that.
Sorry, my apologies, I missed that part you underline. I my defense I'd
say that over the years I've seen so many very experienced maintainers
using epochs incorrectly or trying to defend their non-problematic nature
and goodness, that I've reached a point where I just assume epochs are
generally missunderstood. I realize that can obviously end up coming
across as very condescending. :/
> > they just reset the sorting order of all previous versions and thus
> > invalidate any previous relationships.
>
> Not any more than do upstream version numbers towards debian revisions.
>
> If you consider epoch-zero versions to have "no epoch" (which is wrong),
> then yes, they imply a "reset".
>
> But really, an epoch is just prepending an extra version component
> before the version number. epochless versions have an implicit zero
> (okay, I shouldn't be telling you this).
See my comment above about release continuity.
> Honestly, if this is going to become a requirement, and I didn't want to
> be bothered with it, I would just use . rather than : as my epoch
> separator whenever I need to introduce an epoch. The result regarding
> upgrades etc is *exactly* the same.
Anything that has the same semantic effect of an epoch has potentially
the same ill-consequences. The +really convention is as harmful as
using an epoch, the main advantage is that any uncaught breakage in
relationships will eventually remedy itself once the package gets back
into its previous release continuity.
Using a convention that keeps appending the different version schemas
just to avoid epochs, seems would be even more ugly and confusing than
simply using an epoch when that's the intended use! :)
> > For the valid use cases that's an unavoidable transition that one has
> > to handle, but for the invalid cases it's just unnecessary breakage in
> > the archive and out-of-archive, in most cases silent breakage!
> >
> > Please see
> > <https://wiki.debian.org/Teams/Dpkg/FAQ#Q:_What_are_version_epochs_and_why_and_when_are_they_needed.3F>.
> >
> > > Yes, it's correct that you cannot get rid of an epoch, once it has been
> > > introduced. This has indeed sometimes caused issues when downstream
> > > people have introduced epochs in their versions of our packages, causing
> > > what in effect is an arms race -- but there really is no reason why
> > > asking on -devel will fix *that* particular issue; I don't think that
> > > downstreams who fight with us on epochs will do that anyway, so that
> > > just leaves the debian package maintainer to DTRT and bump the epoch
> > > there.
> >
> > That's really not the right thing to do.
>
> That, too, is just a matter of opinion.
Should have qualified that comment. It was a counter to the absolute
"DTRT". I do think it is wrong as a general principle, because we can
never win. It might be a good enough trade-off for some maintainers to
make life easier for some good-willed downstreams, while I'd still
consider it a bogus change.
> > That's the equivalent of introducing bogus changes into our packages
> > to be bug-compatible with external entities.
>
> True, but sometimes being bug-compatible can be the right thing to do.
"can" perhaps, I don't think "right" is the word though. :)
> > If a downstream unilaterally bumps an epoch, that's their burden to
> > carry.
>
> If our users install epoch-bumped versions of the packages and keep
> bothering us with "my package don't upgrade no more!!1!", just
> introducing the epoch in Debian fixes that easily.
>
> See debian-multimedia.
>
> (yes, that explains the "arms race" bit in my argument, and no, I'm not
> advocating for doing that *in every case*)
Yeah I'm aware of that situation, and that was also why I mention the
"arms race" in the FAQ. IMO that was the wrong thing to do in that case.
If the users are using a 3rd-party repo, where the owners bump the
epoch instead of say recommend using pinning or similar, then that's
the archive and user problem. The correct answer is "don't use that"
or if you do "you get to keep the pieces".
> [...]
> > > or some such. But don't make it a requirement -- because it's one I will
> > > routinely ignore, and I don't think that that should make me run afoul
> > > of policy.
> >
> > If you are "routinely ignoring" this, then your ratio of epoch
> > introduction would worry me much more than you not asking on d-d. ;)
>
> Heh :)
>
> I currently maintain two packages which have a non-zero epoch. I think
> that in both cases the decision to bump the epoch was the right one.
In the two packages you mention, the bump looks entirely legitimate
and for what epochs were intended to be used. For the pmw case I'd
have probably tried to avoid it by talking with upstream so that
they'd have switched to use 4.240 after 4.231 instead of using 4.24.
The other one you have in your DDPO (python-webob), which you were not
involved in, but serves as a nice example, is completely bogus, it was
a release revert, followed by the next upload restoring the continuity.
:(
Thanks,
Guillem
Reply to: