Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
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.
True.
> 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.
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.
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.
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.
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.
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.
> > 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."
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.
--
Could you people please use IRC like normal people?!?
-- Amaya Rodrigo Sastre, trying to quiet down the buzz in the DebConf 2008
Hacklab
Reply to: