Re: many packages fail to build twice in a row again
On 20/12/11 at 22:01 +0200, Peter Eisentraut wrote:
With recent dpkg(-source) changes, many packages are again failing
to build twice in a row, because of uncommitted upstream changes.
Yes, I'd expect that the situation is much worse than it used to be. Not
only because of dpkg-source changes, but also due to ubiquity of build
tools that throw away build tree after build (pbuilder, sbuild,
$VCS-buildpackage...).
On 20/12/11 at 23:16 +0000, brian m. carlson wrote:
If I'm fixing an RC bug, it's very convenient to be able to test a
patch and then rebuild with a different patch if necessary. If the
package doesn't build cleanly N times in a row, or if there are other
problems with the packaging that make it difficult to fix, I usually
go on to fix other bugs instead. Also, when I file a bug report, the
harder you make it to fix your package, the less likely you are to
receive a patch with that report, workaround or not.
Same here.
* Lucas Nussbaum <lucas@lucas-nussbaum.net>, 2011-12-21, 10:41:
I'm not saying that it's not convenient. But on the other hand, several
hundreds of packages probably need to be fixed, which will require a
large amount of manpower
Well, hopefully there are still some non-MIA maintainers left, that can
take care of their own packages. And it's not like these bugs would be
RC, or that we'd have a dead-line to fix them all. Also, such bugs would
be useful even if they were not going to be fixed, because they'd act as
a warning for people trying to modify the package.
that could be used instead to fix problems affecting our users.
You seem to assume that this manpower is somehow transferable to other
tasks. I'm afraid that the result of telling people "don't fix FOO, do
fix BAR instead" can be that neither FOO[0] nor BAR[1] is fixed.
[0] Because you just demotivated a person willing to FOO.
[1] Because the person wasn't interested in fixing BAR in the first
place.
--
Jakub Wilk
Reply to: