Re: RFC: Building a source package directly from a RCS

[Jonathan Nieder <jrnieder@gmail.com>]

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?