On Sat, Nov 03, 2007 at 07:17:32PM +0100, Guido Guenther wrote: > Hi Sjoerd, > On Sat, Nov 03, 2007 at 03:22:14PM +0100, Sjoerd Simons wrote: > > I could see some uses for having a debian branch of upstream in which you > > have the same patches you apply to your deb.. But i don't see the need of > > having the upstream and debian branch mixed (Year and years of > > svn-buildpackage usage showed me that it's never actually necessary).
> People tend to have plenty of branches with upstream code to hack on in > git (these are much easier to handle than in subversion). Not having the > upstream sources in git only makes sense for trivial packages. Well, i tend to follow whatever revision control system upstream uses for that. As i want to follow and send my patches upstream easily :) And for the packaging i just throw the diff (generated by whatever vcs) into my packaging. Works fine for me even with very non-trivial and reasonably heavily patched packages. But ofcourse everyone should use the workflow he likes most :) > > For the suggestion to recreate original tarballs.. I usually find this > > somewhat of a hack and the work of downloading the tarballs is automated > > with uscan anyways. Also for pkg-pulseaudio (which uses git), most of the > > packaging work is done by someone whom i sponsor. And while i trust him to > > do the right thing, i don't want to have to double-check that the tarballs > > he is importing into git are actually the same as upstreams :) > Agreed - this really makes sense when it comes to sponsoring. Given your > aguments above it would also make sense to add a "--git-overlay > --git-tarball-dir=/foo --git-export-dir=../build-area" option. This would do > the following: > * fetch the upstream tarball from git-tarball-dir > * unpack the upstream tarball into build-area > * add the contents of the debian-branch on top of it > This would also address #411206. I would be very happy with that option :) Sjoerd -- Living in the complex world of the future is somewhat like having bees live in your head. But, there they are. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
