On Mon, 4 Jun 2012, Jonathan Nieder wrote:
Santiago Vila wrote:
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:
On Mon, 4 Jun 2012, Jonathan Nieder wrote:
Can you give an example?
I uploaded recode 3.6-19 yesterday, the package I was working on.
If you want to have some fun, ensure you have unstable in a deb-src
source line and try this:
apt-get -d source recode
tar xzvf recode_3.6.orig.tar.gz
cd
retitle 675979 dpkg-buildpackage: --no-unapply-patches should be the default
severity 675979 wishlist
block 675979 by 643043
tags 675979 + wontfix
quit
Santiago Vila wrote:
On Mon, 4 Jun 2012, Jonathan Nieder wrote:
Thanks again for explaining, and sorry for the ramble. I think this
is a
Santiago Vila wrote:
Hmm, why do you say that the usual case does not involve modifying
any source files?
Sorry, I was probably unclear. I meant that running debian/rules
binary usually does not cause source files to be modified.
There is one exception I know of: some build systems run
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
Santiago Vila wrote:
I see it as an inconsistent state which does not make any sense.
As far as I can tell, most people starting from the patches-unapplied
state keep that form in version control. If the build does not
involve modifying any source files (the usual case), they can use
usual
6 matches
Mail list logo
