RE: dpkg-dev: please reject native/non-native version when building native/non-native source packages
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=700177
How to override this new behaviour that breaks backwards compatibility
of existing packages that (abuse) these bad version numbers?
It appears to be enforcing a "Debian Project Policy" onto packages
which are not in Debian.
Can this be reverted, or dpkg-source option provided to override this
new behaviour that is rejecting to build these?
For defaults metapackages it is often useful to have source version
match binary version which matches the version of non-native packages
that it points to.
It appears that e.g. "3.0 (quilt)" + --create-empty-orig is the
migration path for those that (abuse) bad version numbers, but that
also appears to be broken at the moment.
In my opinion, this is a serious RC bug in debian, since source
package out in the wild that one can create with dpkg-source -b . in
stable, are not recreatable with dpkg-source -b . in testing.
Enforcing Debian Policy at dpkg-source -b . level, is not a good idea,
especially when it breaks backwards compat for 3rd parties. We have
lintian, and ftp-master lintian auto-rejects to clense the archive if
so is desired.
If this change is desired, the source package version should be bumped
from 3.0 -> 3.1 and keep 3.0 as it was behaving before (and allow
building with missmatched version numbers).
--
Regards,
Dimitri.
Reply to: