Re: additional build depends / conflicts
* Andreas Barth (firstname.lastname@example.org) [100606 21:20]:
> * Philipp Kern (email@example.com) [100606 16:56]:
> > On Sun, Jun 06, 2010 at 04:19:18PM +0200, Andreas Barth wrote:
> > > As I don't want to get requests to specify packages which are not part
> > > of the controls build-depends (for that, I really would like to seen
> > > an source upload), I consider checking that only packages are depended
> > > on that are part of the source package dependencies anyways (we still
> > > could get a newer version). For conflicts, I don't think that is
> > > advisable, as we might need to conflict with an intermediatly broken
> > > version of something indirectly depended on.
> > So for conflicts we would suddenly be able to fix up builds without
> > touching debian/control, that sounds bad in terms of reproducability.
> > Additional dependencies could be helpful, though.
> well, what's the difference of "depends: python (>> 2.6)" and
> "conflicts: python (<= 2.6)" (with an sourceful dependency on python)?
> Otherwise, I'm happy to say "buildd needs to modify the changelog",
> perhaps that's the best anyways.
> (I think we should be more strict with depends on *new* packages,
> because "depends on something that's not in a plain chroot" might
> activate new features in some packages, even though that's obviously a
So, any more opinions on that? I might get to the implementation phase
soon, now that non-free works.