Re: many packages fail to build twice in a row again
Lucas Nussbaum <lucas@lucas-nussbaum.net> writes:
> On 20/12/11 at 23:16 +0000, brian m. carlson wrote:
>> On Tue, Dec 20, 2011 at 09:36:47PM +0100, Lucas Nussbaum wrote:
>> > 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. Fixing
>> > > this was a lenny release goal, maybe it should be one again?!? Most
>> > > importantly, maybe someone who has access to one of those build grids
>> > > can run the old tests again, because I feel by accidentally stumbling
>> > > upon these problems we will not be able to find and fix many of them any
>> > > time soon.
>> >
>> > Is it really worth it? There are many ways to work-around this, such as
>> > using a temporary git repo to be able to 'git clean' and return to a
>> > clean state before each build.
>>
>> 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.
>
> 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 that could be used instead to fix problems
> affecting our users.
>
> Maybe it's better to fix those bugs when they are encountered, rather
> than have a systematic effort to fix them all?
I think it is beter to have them fixed before someone needs to write a
patch for them.
The way I prepare a patch for a debian package goes like this:
1. apt-get source (or git/svn)
2. debuild -us -uc -b (see if it actually builds before changes)
3. dch --nmu
4. edit files
5. debuild
6. dpkg -i && test
7. go back to 4 till it works
8. debuild -us -uc -S
9. rename debain/patches/debian-changes-version or debdiff the dsc files
10. reportbug -A patch package
If the package does not build N times then steps 4/5/6 are more work.
But also step 9 often becomes much more work. The patch becomes a lot
larger, usualy because auto* files are included, and then needs extra
cleanup before being able to send it.
> If you are interested into mass bug filing about issues that affect our
> users, see http://lists.debian.org/debian-qa/2011/08/msg00091.html for a
> list of 1073 packages failing to install, remove, or upgrade from
> squeeze.
How large is the intersection of those 1073 with the packages that don't
build multiple times? Lets fix that subset first. Easier to fix 2 bugs
with a single upload. :)
> Lucas
MfG
Goswin
Reply to: