On Wed, 2018-02-14 at 18:52 +0100, Vincent Bernat wrote: > ❦ 14 février 2018 16:09 +0200, Lars Wirzenius <liw@liw.fi> : > > > > > It's not only an infrastructure problem. If you Depends on X (>= 1.8), > > > > this will be true with X 1:1.6 as well. ... > That's exactly the point. You wanted X >= 1.8 and you get X 1.6. I don't think that's what you said, or at least it was hard for me to understand it that way. > More concrete example (now a bit in the past). On Wheezy, you want to > depend on a 1.8 JRE (you package independently). You put > default-jre-headless (>= 1.8). Since you have forgotten about the epoch, > this pulls Wheezy default-jre-headless (1:1.7-47+deb7u2). So you add the > epoch to both your own package version default-jre-headless (1:1.8-1) > and to the dependency. All good. You upgrade to Jessie and rebuild > everything. Jessie comes with default-jre-headless (2:1.7-52) which > shadows your default-jre-headless (1:1.8-1) package. I think I now understand what you mean: you're actually worried not that version numbers compare in illogical ways, but that people write wrong versions in dependencies. I don't think that has anything to do with epochs, and I don't think getting rid of epochs would actually solve that problem. The root cause for people getting version numbers wrong in dependencies, in my expeience as a Debian developer, is that not all version numbers are very simple, and that updating them is a manual task. It's true that epochs make version numbers a little more complicated, but not as much as sheer length. The median length of version numbers in stretch is 8 characters, looking only at version numbers without an epoch. Getting those wrong is very easy, even without epochs, and not really harder than with epochs, in my experience. I admit an epoch may trip someone, but it's not happening often enough that it's a problem worth solving by getting rid of epochs, in my opinion. I know of only two ways to get version numbers correct: automation and testing. For shared libraries, we have automation. Maybe we can have that for other classes of dependencies as well. For everything else, we're going to need testing. Automating all generation and updating of runtime and build time depencies would be a good thing to have. Not an easy thing to achieve, of course. I, for one, would welcome a general AI for automating this. Skynet is a worth it if we can get versioned dependencies right every time.
Attachment:
signature.asc
Description: This is a digitally signed message part