Bug#891216: seconded 891216: Requre d-devel consultation for epoch bump
On Thu, Jun 28, 2018 at 04:27:12PM +0200, Guillem Jover wrote:
> 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!
How and in which ways are bogus epochs harmful that uploading a package
with the +really convention is not?
Downgrading a package is harmful, that's true. In that respect, using a
bogus epoch is problematic. However, none of those harmful effects are a
result of the use of the epoch; instead, they are a result of the
downgrading of a package.
Using an epoch in that way is harmful; not because the file now has an
extra non-implicit version number (which is just a technical thing), but
because you're effectively causing a downgrade on a user's system which
breaks dependency relations in unexpected ways.
Should we discourage downgrading packages? Yes, absolutely. But that's
not what this proposal does.
> Pre-Depends are localized in a single package, and their effects can
> be easily tested,
Not unless you can come up with a solution for the halting problem.
> 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.
I guess your definition of "global effect" differs from mine.
At any rate, this isn't really the core of my argument, so meh.
[...]
> 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.
Yes, but the issue lies not with epochs; rather, it lies with the
fact that you're downgrading the upstream software, which happens
regardless of whether you use an epoch or the +really convention.
Note: I'm not recommending people use epochs for when the +really
convention would suffice. In fact, I'm recommending against downgrading
at all, I think we should avoid those if even remotely possible. But
adding bureaucracy around epochs because people misuse them for things
that they weren't made for and *that are a bad idea to begin with* seems
like a pretty bad idea to me.
[...]
> 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. :)
Yes, there is that :)
[...]
> generally missunderstood. I realize that can obviously end up coming
> across as very condescending. :/
No worries, been there done that.
[...]
> > True, but sometimes being bug-compatible can be the right thing to do.
>
> "can" perhaps, I don't think "right" is the word though. :)
Fair enough :)
[...]
> > 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.
Honestly, I should have called it 4.23.1 rather than 4.231, which is
what upstream intended but which he couldn't encode due to
implementational details.
Ah well.
> 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.
> :(
Yeah, like you say, I wasn't involved. I really only did a single
sponsored upload of python-webob once, don't even remember the details
of it...
Anyway, I've said my thing, I think people know about it now. I don't
think we should make this a requirement in any form or shape (but would
be happy with a strong recommendation if needs be); if I'm alone with
that sentiment though, then that probably means the consensus disagrees
with me and I'll have to live with it.
So, EOT for me.
Regards,
--
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: