[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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



Jonathan Nieder <jrnieder@gmail.com> writes:

> 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.

With the above the debian/patches/* is generated from the feature
branches and the working dir. So if you just edit master the changes
collect in debian/patches/debian-changes[-version]. Thenm when you are
finished testing and everything works, the right thing to do would be to
create a new feature branch and cherry pick the commits for that
feature.

> Where does your tool fall in this spectrum?  What branch is checked
> out when the wrapper is called?

Currently my script does check out the debian branch. But that is just a
proof-of-concept implementation. You could just as well checkout the
debian subdir from the master branch, provided your RCS allows that. Or
just plain "cp -a $WORKDIR/debian $TMPDIR/". With uncommited changes (to
the debian dir) the last would be neccessary anyway. Often I like to
test build something before commiting it so that is something to
implement if the overall idea is sound.

MfG
        Goswin


Reply to: