Hi Goswin, Goswin von Brederlow wrote:
> Now to build a source I do the following: > > 1) if missing: create the orig.tar.ext using pristine-tar > 2) if needed: update the auto-patched branch > 3) Check out debian dir > 4) if used: Create debian/patches/* from branches, stacked git, > mercurial patch queue > 5) generate debian/patches/debian-changes[-version] by "diffing" > auto-patched against master > 6) Create debian.tar.ext from 3+4+5 > 7) Create a .dsc file from 1+6 > > Overall this takes full benefit of the RCS and avoids for every (source) > build a costly unpacking of orig.tar.ext, patching and diffing the > source by using the superior features of the RCS to do the same job. > > Curently I've put together a little wrapper, call it a proof-of-concept, > that does exactly that (except step 2). I use the 3.0 (custom) format > and in step 7 I run > dpkg-source --target-format="3.0 (quilt)" -b foo-1.0 foo_1.0.orig.tar.gz > foo_1.0-1.debian.tar.gz Sounds interesting. What is the user experience like? With separate debian dir, sometimes making changes can be a pain: checkout patched-upstream fix a build system bug checkout debian update rules checkout master merge patched-upstream merge debian test ... go back and fix things ... while if the patched upstream + debian dir is tracked with a single tree, it can be easier: checkout master fix a build system bug update rules test ... fix things ... with the main downside being that it can be hard to generate debian/patches/* from a history with debian dir and upstream changes mixed. Where does your tool fall in this spectrum? What branch is checked out when the wrapper is called? -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/20100630175052.gb21...@burratino
