> Given that this actually changes the definition of Source-Version, a
> warning message should probably be sent to debian-devel-announce if this
> is adopted. However, I think this will be correct the majority of the
> time Source-Version is used. Only occasionally does a dependency actually
> need to be so strict that a binNMU breaks the relationship. (This could
> happen in the case of a -dev package depending on a library package, in the
> subcase where the binNMU built the library against different libraries,
Every dev package has a strict dependency on its library and for good
reason. When binNMUing a library with this patch the binNMUed -dev
would depend on the broken library and the recompiled library wouldn't
even be installable.
I think that this change, while still good, should be done in 2
steps. First add Binary-Version and get all dev packages (and other
known strict binary-version depends) to use it. When the majority has
done so only then start stripping the Source-Version.
> If you'd rather retain the old not-quite-accurate meaning of
> Source-Version and add something like Indep-Version, that would really
> be just as good, though perhaps slightly more confusing to developers of
> the future; the main point is to provide a standard binNMU-safe way
> of allowing exact versioned dependencies of arch:any packages on arch:all
> packages. While providing the other meaning for those who need it.
> Anyway, I think either this patch, or the 'backward-compatible' version
> introducing Indep-Version and retaining the old meaning of Source-Version,
> is a good idea. Thoughts?
$ dpkg --compare-versions "1.2-3.0.1" "<<" "1.2-3sarge1" || echo no
$ dpkg --compare-versions "1.2-3+b1" "<<" "1.2-3sarge1" || echo no
The whole binNMU versioning (or security versioning) has to be
rethought. Neither the current nor the latest sbuild --make-binNMU
scheme (second line) works with security updates.