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

Re: binary NMUs and version numbers

At Thu, 25 Nov 2004 13:53:36 +0100,
Andreas Barth wrote:
> - In that binary package, the source version is used as 1.2-3.0.1 which is not
>   really true (at least, no source with that version exists in the
>   archive). So, katie needs to do special handling there.
> The last issue could be solved with any handling, even with the current
> one, so I will ignore it in the rest of this mail.

Yes, however I feel it's not straightforward handling for a long time.

> The other idea is to use a "binary epoch" for binary-only NMUs, i.e.
> 1.2-3^1 for the second set (with the implicity epoch of 0 if none is
> given), and a new sorting rule that 1.2-3^1 >> 1.2-3, but smaller than any
> other suffix (and of course, ^ just stands "for a new character"). The
> advantage is that this solution is the nicest one from the theoretical
> point of view. It solves both problems with britney and the security
> uploads, but the disadvantage is that we need to teach dpkg first how to
> handle that new character before we can use it. So, we probably should fix
> that in sarge, so that we can use the new character in etch than.

It's interesting idea.  I second this "binary (suffix) epoch", and it
seems no drawback (except new dpkg is needed).  I also think it's nice
to support in sarge.

I think this suffix epoch works as the current (prefix) epoch, is it
correct?  (Thus, we shouldn't recognize "1.2-3^1.1" and "1.2-3^1a").

-- gotom

Reply to: