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. -- To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/canbhlujhoq1nmtdjofq0nrm-mtp_7muxlhddmpae9moo8up...@mail.gmail.com