On 07/03/12 09:34, Neil Williams wrote:
> Turn the problem around - if someone (me) comes to you about one
> of your packages with a set of changes which are necessary to be
> able to rebuild your package, say, without perl or without SSL or
> without LDAP support - how would you prefer that to be explained
> and debugged? A set of sed and awk lines for debian/rules or a
> clean set of patches to debian/ files?
If you want me to incorporate changes, I'd prefer them as a git patch
(series) for debian/ in my packaging repository, or failing that, an
equivalent of the output of nmudiff (which is roughly equivalent to a
single git commit touching only debian/).
This is somewhat orthogonal to the format in which you distribute your
source packages, though, surely? If I obtain the .debian.tar.gz for a
modified version of my package and want to merge the changes,
debian/changelog tells me where we diverged, and to get from there to
a nice patch, I'm quite capable of operating diff on my own :-) - but
if you work against the tools by patching/sedding the debian directory
at build time rather than just making the changes, I'll end up with a
diff-of-diffs or a sed recipe for reproducing the diff, rather than
the diff I wanted.
If you don't want me to incorporate changes (for instance because
they're Emdebian-specific things which actively remove functionality),
then I don't care how you maintain them - do whatever works - but I
would suggest that branching the source package in a VCS (hint:
git-import-dscs --debsnap) is likely to be more sustainable than
patching or applying sed/awk at build time.
S
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/4f57380f.5020...@debian.org
