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").
Regards,
-- gotom
Reply to: