Ian Jackson <ijack...@chiark.greenend.org.uk> writes: > After there is only one consumer [of the package-provided > ‘debian/rules’ build interface], it will be somewhat easier to change > [the policy so that interface is not the standard].
>From the rest of your message I infer that the mention of “one consumer” there refers to (current or future) ‘dpkg-buildpackage’, is that correct? > Important consequences of my views include: > > * The package-provided rules interface needs to remain managed as part > of policy (and to continue to have a controlled approach to updates, > etc.). > > * The interface is not *defined by* dpkg-buildpackage: ie it is still > possible for dpkg-buildpackage to have a bug where it does not > implement the de-jure interface. > > * Packages may still need to work around bugs in old versions of > dpkg-buildpackage; conversely, new versions of dpkg-buildpackage may > need to work around bugs in old packages. > > * For a long time, packages should try to be compatible with old > builders which invoke rules directly, even old builders other than > dpkg-buildpackage. I had been under the impression the build tools (SBuild, PBuilder, etc.) invoke ‘debian/rules’ directly, and so are a good way to test that compatibility. Evidently that impression is wrong, and the use of those build tools is not helping to find such bugs. What tools exist to allow package maintainers – as many as possible – to get easy (automatic?) notification when the package they maintain is not presenting a compatible ‘debian/rules’ build interface? -- \ “Very few things happen at the right time, and the rest do not | `\ happen at all. The conscientious historian will correct these | _o__) defects.” —Mark Twain, _A Horse's Tale_ | Ben Finney
