Re: okteta

[Joerg Sonnenberger <joerg%bec.de@localhost>]

On Sun, Aug 20, 2023 at 10:13:59PM +0100, David Brownlee wrote:
> On Sun, 20 Aug 2023 at 19:38, Joerg Sonnenberger <joerg%bec.de@localhost> wrote:
> >
> > On Sun, Aug 20, 2023 at 12:35:52PM -0400, Greg Troxel wrote:
> > > I think it's a simple matter of someone producing a patch for epoch.  I
> > > am not aware of any real objections to doing this in a way with
> > > semantics that match the other systems.
> >
> > That's not the reason. The reason we don't have epoch numbes is because
> > the existing system handles the case well enough. There is just no
> > generally agreed standard on what to use as magic high component number.
> 
> I would have to disagree there - the issue of an upstream version
> reducing is rare, but we do not have any way to handle it, and have
> this issue _every_ time.

Yes, we have exactly the necessary mechanism and had it for years, but
every time the problem happens, people discuss that we need yet another
magic version numbering scheme.

>
> The three other package systems all have effectively the ~same well
> defined way to handle it - epoch is a small incrementing integer which
> prefixes the other version information, and if omitted defaults to
> sorting before any other value.

So how is this any different from calling the version 999.1.2.3?
Upstream didn't bless it? Oh wait, upstream couldn't manage to create
proper monotone version numbers, so why should we care about using their
mess? Hint: epoch numbers do not solve this problem as they are still
different from the upstream version number for every purpose that
counts.

Joerg