Linux Archive

Linux Archive (http://www.linux-archive.org/)
-   Debian dpkg (http://www.linux-archive.org/debian-dpkg/)
-   -   RFC: Building a source package directly from a RCS (http://www.linux-archive.org/debian-dpkg/393071-rfc-building-source-package-directly-rcs.html)

Goswin von Brederlow 06-30-2010 02:05 PM

RFC: Building a source package directly from a RCS
 
Hi,

the other day Ron Lee mentioned on irc how he builds a debian source
package from git with a wrapper script and there was some discussion of
the use and danger of the various -sX flags to dpkg-source.

His method creates both the .orig.tar.gz and .orig directory from his
git repository and tells dpkg to use them in an effort to save
extracting the orig.tar.gz needlessly. But that still means dpkg will
diff the orig against the working dir to create the diff.gz and risks
diverging orig.tar.gz and .orig dirs. And there are some problems
adapting this to the 3.0 formats. So the method isn't really optimal.


So lets look at this fresh. I'm assuming the following workflow and
repository layout:

upstream - upstream source from the orig.tar.ext
pristine-tar - delta + id to recreate orig.tar.ext
debian - debian directly only (without patches if patch-* is used)
master - working dir

Optional (or stacked git ot mercurial patch queue):

patch-foo - upstream + foo patched in
patch-bar - upstream + bar patched in
patch-baz - upstream + baz patched in

Automatic branch:

auto-patched - upstream with all patch-* applied


Resolving merge conflicts for patch-* in some way is left to the
implementation. For simplicity lets assuming the patch-* branches are
already serialized and merge conflict free.

The above is just an example. What is required is that the orig source
is there, the debian dir is there and a branch with debian/patches/*
applied can be maintained (auto-patched).


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



So what do you think about this approach?

MfG
Goswin


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87iq50k44b.fsf@frosties.localdomain">http://lists.debian.org/87iq50k44b.fsf@frosties.localdomain

Jonathan Nieder 06-30-2010 05:50 PM

RFC: Building a source package directly from a RCS
 
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 debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 20100630175052.GB21228@burratino">http://lists.debian.org/20100630175052.GB21228@burratino

Goswin von Brederlow 07-01-2010 08:36 AM

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


--
To UNSUBSCRIBE, email to debian-dpkg-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Archive: 87d3v7ioo3.fsf@frosties.localdomain">http://lists.debian.org/87d3v7ioo3.fsf@frosties.localdomain


All times are GMT. The time now is 12:14 AM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.