Re: deprecating needs-recommends

[Ian Jackson <ijackson@chiark.greenend.org.uk>]

Michael Biebl writes ("Re: deprecating needs-recommends"):
> I have a package (firewalld) which has optional dependencies like ipset
> or ebtables. If those are not installed, firewalld will log a warning
> and continue with the functionality disabled.
...
> Now, if needs-recommends is going to be deprecated/removed, I'll have to
> specify the Recommends twice: once in debian/tests/control and
> debian/control and I don't like this duplication as this is prone to get
> out-of-sync.
> 
> Just wanted to provide a data point why it might be useful to keep
> needs-recommends.

I have found that in practice, debian/tests/control often has too much
stuff in it that needs to be kept in step with the rest of the
package, to handle this manually.

So instead, when things get nontrivial, I have a script to update
debian/tests/control.  Well, really, I generate it from template(s)
and other information found in the source.

I think your case is just an example of this kind of problem.

Unlike d/control it is not a big problem d/t/control is not updated.
My approach to detecting a failure to rerun the d/t/control generator
is to have a test which runs the generator and fails if the output is
not identical to the current file.  So not updating the test list is
itself a test failure.

I commit the resulting d/t/control to git.  This is slightly ugly but
not a practical problem.  In particular, any merge conflicts are
easily resolved by rerunning the generator.

Ian.

-- 
Ian Jackson <ijackson@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.