Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
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.
> > 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,
I know that.
> 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).
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.
> 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.
> 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.
> 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*)
[...]
> > 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.
No, I won't routinely bump the epoch. But when I need to, I will more
often than not ignore such a requirement, is what I meant :)
--
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: