Bug#525935: Bug#403246: [buildd-tools-devel] Bug#403246: Still occurs

[Robert Millan]

On Tue, Apr 28, 2009 at 03:38:42PM +0100, Roger Leigh wrote:
> I'm not sure that a separate type of Build-Depends field in the control
> file is necessary.  Surely a build dependency is required or not required;
> there isn't really a case in between where it /might/ be required, is
> there?  (Excluding arch-specific, which is already catered for.)

Yes.  It's very common;  imagine program "foo" whose configure script
checks for "libbar".  When "libbar" is found, it will enable features that
depend on it.  However, "libbar" is only available in sid and not in
stable.

> Should backporters not simply alter the build-depends to be correct
> in the backport environment, and/or backport any needed dependencies
> if they can't be satisfied by older packages?

Backporters can do that, but it means more work.  If this problem was
solved, most backports could be maintained automatically.

> I, for example, keep separate debian and debian-backports branches
> in a VCS so that such deviations can be easily tracked.

It's going to be a branch either way;  the difference is between branching
the whole thing or just a line in debian/control.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."