On Wed, Aug 02, 2006 at 08:36:18PM +0200, Eduard Bloch wrote: > #include <hallo.h> > * John Goerzen [Wed, Aug 02 2006, 01:01:51PM]: > > On Wed, Aug 02, 2006 at 08:47:01PM +0300, George Danchev wrote: > > > > to learn how we deal with this all. > > > > > > This is fine, but (again) you forget about your 'apt-get source' users, > > > which > > > > NO. They need not care. They can just hack and send me diffs. My > > debian/changelog will already document what has been going on anyway. > > Heh. So they need two copies, one where they do modifications, then diff > those and send you the diff. Or they need to change debian/changelog and > learn to use interdiff. All that is more work that just callin > "dpatch_edit_patch foo".
$ dpatch_edit_patch zsh: command not found: dpatch_edit_patch Yep, that was very little work. Even less benefit, though. Oh, you meant dpatch-edit-patch, perhaps? That's great, but there's plenty of packages that contain debian/patches/ were dpatch-edit-patch will get you nowhere. And when you do find a package where dpatch-edit-patch "works", all it does, effectively, is make two copies, one where you do modifications, and then diff those and store the diff. Gee that sounds familiar. dpatch-edit-patch also suffers from the difficulty that you need to manually revert bits and pieces that you don't want in your final dpatch, like (for instance) updated changelog entries (which you made to make test builds to ensure that everything's working OK before going through the rigamarole of wrapping up the patch, and then reopening it again -- a full-tree diff, removal, and re-copying -- if you got it wrong. > Why do dist.VCS fans always talk about patches like the would rain from > the sky just so? Because we've moved on from being our own VCS (a la dpatch) and are now using an automated tool to track things *for* us, instead. So now working with patches is simple and straightforward. > > > are not supposed to be aware of your SCM, where your repo is, patches > > > applied > > > to the upstream source and why they have been applied. I.e. if you have > > > patches, do them debian way (using a debian patch system) even using SCM > > > to > > > manage your whole packaging. Your orig.tar.gz must be really original > > > tar.gz, > > > and your diff.gz should hold whole debian-specific thing. > > > > I am quite well aware of that and it is trivial to do. > > And if the user has more than one patch which needs to be maintained > separately, is it still is still trivial FOR HIM? (or her) HE (or she) can work out how to make things work FOR HIMSELF (or herself). Chances are, no matter which system you choose, someone out there isn't going to like it. So why hamstring yourself with a sub-standard system that you don't like working with, just to please some minority of users? - Matt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]