[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Debian part of a version number when epoch is bumped

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

Reply to: