Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
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:
> > Wouter Verhelst writes ("Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump"):
> > > I would oppose this change.
> > ....
> > > 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).
> >
> > My perception of our experience is that trying to get people to make
> > the right choice solely by writing things in documents is not
> > effective.
> >
> > Epochs are frequently misunderstood and used where it would have been
> > better not to use them. Proper usage of an epoch is sufficiently rare
> > that asking for a review is reasonable. We do not have a central code
> > review board or anything; debian-devel is the closes thing we have.
I think I've spotted more wrong usage of epochs from reading
changelogs (when it's too late already), than correct ones, TBH.
> > 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. :)
> 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.
No, they are not just a decorator for the version, they have a
semantic meaning, they just reset the sorting order of all previous
versions and thus invalidate any previous relationships.
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's the equivalent of
introducing bogus changes into our packages to be bug-compatible with
external entities. If a downstream unilaterally bumps an epoch, that's
their burden to carry.
> Yes, it's correct that epochs cause confusion, because some bits of our
> infrastructure drop the epoch in the filename. I submit that that is in
> fact a bug in that bit of infrastructure; epochs are a critical part of
> the version number, and they should not be dropped, ever.
I don't think this is a black/white thing, it's a matter of trade-offs,
IMO. Using colons in filenames can cause problems in various places,
filesystems, or even unintended network access from tar (w/o using
--force-local), for example, etc.
> But if we're going to introduce the *requirement* to ask on -devel for
> every nitty bitty thing that might possibly somewhere down the road
> cause some confusion in some inexperienced developer, then in the end
> the -devel mailinglist will devolve to a list where senior DDs come by
> to ask "can I please introduce a postinst to my package?" and that's
> just a waste of everyone's time.
The big difference is that introducing epochs is (currently) an
irreversible process. Even Pre-Depends can be fixed after the fact!
And I've never been bothered for having to send a notice to d-d, even
when I was pretty confident I was right, as in:
"Hey I'll add Pre-Depends blah for package blur in X days. Please
shout if you think this is a problem."
If I had to choose between the two, I'd remove the requirement for
Pre-Depends.
> That (and a feeling that I'll just balk at wasting my time by asking on
> -devel "please pretty please can I introduce an epoch please") is why
> I'm oposed to introducing this requirement.
I guess I don't see it as some kind of begging. For me it's a change that
has far wider consequences, just like any other transition, and where
peer review is good, even if I'm absolutely certain I'm right. You don't
even need to word it as begging, just set a deadline and then proceed
after that.
> > > But requiring a consensus on -devel seems like wasting people's time to
> > > me.
> >
> > I don't care whether it's consensus or consultation. In practice
> > there are not going to be big arguments about this.
>
> Which is another reason why we shouldn't introduce the requirement.
>
> I'd be okay with a recommendation along the lines of
>
> "Please note that introducing an epoch is an irreversible action. If
> you're uncertain of whether the introduction of the epoch is the right
> thing to do, it is best to ask on the debian-devel mailinglist."
Well, I assume all the many maintainers who've wrongly added bogus
epochs were certain that was the correct thing to do.
> 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. ;)
Thanks,
Guillem
Reply to: