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

Re: binNMUs and versions



On Sat, Jun 12, 2010 at 06:02:03PM +0200, Philipp Kern wrote:
> On Sat, Jun 12, 2010 at 05:17:49PM +0200, Kurt Roeckx wrote:
> > On Fri, Jun 11, 2010 at 10:51:36PM +0200, Andreas Barth wrote:
> > > > I'd rather see the binNMU version in the installed_version field - after
> > > > all, for that architecture, that is the version that is installed. When
> > > > filing a binNMU it is confusing to first see it go from 1.0-1
> > > > (Installed) to 1.0-1+b1 (Needs-Build) to 1.0-1+b1 (Built) to 1.0-1
> > > > (Installed). I'd expect it to stay at 1.0-1+b1 (Installed), if you know
> > > > what I mean.
> > > Eh, I need to translate myself I assume:
> > > "I would tend to put the version number including the binary epoch
> > > (e.g. 1.2.3+b1) in all fields, ...".
> > I'm not sure how you'll get that to work, because you wouldn't
> > know what the source version is anymore?
> 
> What we see in that version field is a faked version anyway.  It's not
> about the binary version, it's either source version or
> concat(source version, '+b', binNMU version).

Right, and we probably don't properly handle the case where a
source versions generates differerent binary versions then
the source version, not taking binNMUs into account, and then
doing a binNMU of that.  But those packages probably don't support
binNMUs either.

But it's still important that we know what the source version is,
we can't assume that a "+bX" binary version is actually a binNMU.


Kurt


Reply to: