Bug#824495: debian-policy: Source packages "can" declare relationships
> > While we are at it, I understand, because it would involve a huge
> > amount of computation to determine, that we can't test every package
> > against every other binary package to discover undeclared
> > build-conflicts.
>
> Well, indeed. In fact, this is the reason why I don't see how we could
> introduce a requirement to use Build-Conflicts into Policy. We would
> not be able to determine whether we were making packages buggy by doing
> that.
Sorry, I forgot some details about the case that prompted me to file
this report:
I was building all the packages in stretch, and to save time and
bandwidth for each build, I installed debhelper in my chroot
(as nearly every package uses it).
The source package failed to build from source if you had "automake"
installed in the chroot. At the time, automake was installed by
default when you installed debhelper.
So it built ok only if you take the ultraorthodox path of having a
completely minimal chroot, but it would fail for anybody who, like me,
also installed debhelper and its default dependencies in the chroot.
What I would like to avoid is maintainers recommending or even
*suggesting* the user to uninstall the conflicting package
as a way to "solve" the problem, as it happened here:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=824011
Maybe I was a little bit rude at the time by changing the severity
while discussing, but I would also consider rude that a maintainer
even suggests that this FTBFS problem is user's fault and not a
packaging bug.
So: What about "packages should declare Build-Conflicts when the
build-conflict happens against a very common build-dependency"?
(Or something like that).
If we don't do anything like that, not even a recommendation, an
example, or a typical use-case for build-conflicts, maybe we could
declare that the only acceptable way to build packages is to have a
completely minimal chroot and declare build-conflicts obsolete...
Thanks.
Reply to: