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 msgmerge,
causing translation catalogs to be modified.
[...]
> So, consider the following flow:
>
> (A) ===> (B) ===> (C)
> |
> (D)
>
> I want to reach C, which is "package with patches applied and built".
[...]
> However, I still want to reach (C), not a dead end state like (D).
It is a little simpler to think about the states being placed with
respect to two axes:
build products absent (A) === 1 ==> (B)
4 ⇑ 2 ⇓
build products present (D) <== 3 === (C)
unpatched patched
1. quilt push -a
2. debian/rules build
3. quilt pop -a
4. vcs clean
The trouble with both of our abstract explanations is that this does
not explain how the proposed semantics avoid hurting actual users in
workflows they already use.
The underlying problem seems to be that for packagers who were already
using quilt, muscle memory involves both keeping the unpatched source
in a version control tree and running
dpkg-buildpackage
debian/rules clean
vcs commit
to test-build and then commit. Neither of the proposed sets of
semantics keeps that working. "debian/rules clean" does not unapply
patches. Letting dpkg-buildpackage error out with a message that
suggests running "quilt push -a" is tempting, but the current behavior
of applying patches automatically for a one-time build has been around
for a while.
Ciao,
Jonathan
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
