On Mon, 4 Jun 2012, Jonathan Nieder wrote: > Hi Santiago, > > Santiago Vila wrote: > > > The problem is that at the same time, dpkg-buildpackage seems to > > unapply the patches *after* building the package, when the source tree > > is full of executables, objects, Makefiles and so on. This is when a > > disaster might happen, as some of the patches might be required so > > that the clean target works properly. > > > > As a result, building the package twice in a row by invoking > > dpkg-buildpackage twice fails. > > Can you give an example? I would think that the second > dpkg-buildpackage would apply patches again, so in principle I don't > see how this would break.
You are right, I had not tried that. The second dpkg-buildpackage would indeed realize that the patches are not applied and it would apply them. However, what I was trying over and over again was this: dpkg-buildpackage debian/rules clean dpkg-buildpackage This is what it does not work, and I think it should. It could be argued that the possible states of a package may be thought as being in a stack: A. Unpackaged with patches not applied. B. Unpackaged with patches applied and clean tree. C. Unpackaged with patches applied and built. The state "built with patches unapplied" is neither A nor B nor C, so it does not fit in the stack easily. Im fact, it is a dead end: if you want to go to C, you would reapply the patches, which is easy, but if you want to go to B, you would have to reapply the patches as well before doing the clean, as not doing so might result in a disaster. So: how it is useful at all that the patches are unapplied, then, if whatever other "usual" state that you want to go should start by reapplying the patches? I see it as an inconsistent state which does not make any sense. -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
