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