Re: Use of the Build-Conflicts field
On Fri, Feb 15, 2019 at 08:59:41PM -0700, Sean Whitton wrote:
> Use of the Build-Conflicts field is currently mostly optional, but Ian
> Jackson and I have been working on text for Debian Policy that would
> require its use in certain cases. See #824495 for the discussion.
>
> There are two cases which we think that everyone would agree that there
> is a bug, but we are not sure that the bug would be considered to be RC.
> We are posting to -devel to see if, in fact, we do have a consensus that
> these bugs would be RC, or not.
>
> (1) a package FTBFSs when: another package that is part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
sev:Important, I'd say.
> (2) a package FTBFSs when: a package that is NOT part of a "reasonable
> standard development workstation install" is present, but the first
> package does not declare a Build-Conflicts against the second
The "reasonable standard dev workstation" differs from an expected
environment of someone working on that particular stack of packages. Ie, a
NMUer vs someone involved. The latter might be pretty non-standard -- for
example, the vast majority of current pmem developers have /usr/bin/valgrind
come not from the Debian package but from a non-packaged not-yet-upstreamed
fork named pmemcheck. If we had it in the archive, it'd be a prime case of
NMUer-vs-dev discrepancy.
Thus, I'd instead suggest: is the package that should Build-Conflict likely
to be found together with the package being built? If yes, sev:RC. If not,
sev:meh.
> It is worth noting that in both cases, the fix is highly non-disruptive
> to maintainer workflows: you just add the build-conflicts metadata. But
> how easy it is to fix the bug does not determine whether or not that bug
> is RC.
An archive rebuild in a chroot-from-hell would be pretty likely to find such
problems, especially if you do several rebuilds with randomized package sets
(kind of randconfig). But this doesn't strike me as the best use of our
limited supply of tuits.
> For the purposes of this e-mail, let's assume that we have a good grasp
> on what a "reasonable standard development workstation install" means.
Nope.
Meow!
--
⢀⣴⠾⠻⢶⣦⠀
⣾⠁⢠⠒⠀⣿⡁
⢿⡄⠘⠷⠚⠋⠀ Have you accepted Khorne as your lord and saviour?
⠈⠳⣄⠀⠀⠀⠀
Reply to: