Johannes Schauer writes ("Re: Feedback on 3.0 source format problems"):
> Sbuild could do this cleanup itself if there was a way to
> automatically determine whether the user would like their tree to be
> patches applied or unapplied.
This would have to be some kind of (perhaps package-specific) personal
configuration, I think.
> I do not even know of a way to determine upfront whether a source
> tree is patches applied or unapplied (that check has to be
> independent of the source format).
This is, in the general case, clearly impossible. As a simple
example, consider the result of the following:
# .oO{ somepackage is broken }
dgit clone somepackage && cd somepackage
# .oO{ hrm I wonder why it is broken - oh there is only one patch }
# .oO{ oh the breakage is in the busted patch "add zorkmids" }
git revert -n :/'add zorkmids'
git commit
Now the tree is exactly identical to a patches-unapplied tree. But
the user wanted it to drop the patch. Tools should not reapply it.
> This also brings me to a question about the --unapply-patches option. The man
> page says:
All of this applying and unapplying of patches around build operations
is complete madness if you ask me - but I don't see a better approach
given the constraints. dgit sometimes ends up doing this (and moans
about it), which is even madder given that dgit has git to help it
out.
Ian.
--
Ian Jackson <ijack...@chiark.greenend.org.uk> These opinions are my own.
If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.
