On Mon, May 30, 2005 at 05:24:42PM -0500, John Goerzen wrote: > I'm not sure this is really a bug. If the file is truly boring, then > the clean target in debian/rules should be removing it, and it should > never be in the .orig.tar.gz to begin with. Am I missing something > here?
Just to add to that last message. Repackaging upstream source to get rid of those generated files breaks a couple of "shoulds" in the developer's reference. But as this is only the best practices and is not a normative policy, it may be ugly but it's not really a bug. If I may to start throwing wishlist items around, then I would wish for darcs-buildpackage to have only as an optional feature that %(package)s.upstream repo matches with orig.tar.gz. Those darcs-buildpackage features that depend on that identity would be disabled in that case. Just darcs removing the generated files in the work directory would have the generated files reintroduced on new upstream releases. Or would that matter, if the patch from the debian repository would remove those files right away from the repository, would darcs not take a performance hit then? I think that having debian/rules clean rm the generated files and altering orig.tar.gz thus would be technically the best solution, but yet I hesitate to break the best practices laid out in developer's reference with this. I guess you're likely to make a more informed choice on what to do about this one than I do. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
