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

Re: svn-buildpackage etc., mergeWithUpstream, and dpatch/quilt/cdbs again

I am not sure how would I survive without VCS (first CVS and now SVN).
And there are probably more efficient ways than I use, but I just wanted
to share.

I find mergeWithUpstream "mode" useful whenever the upstream package is
huge, and you don't want to "pollute" SVN with that much of irrelevant
for packaging files. And bringing modifications in and inspecting full
source is just 1 step away (s-b-e) after u-0 (if you don't have upstream
source readily fetched)

For inspecting .diff files I find lsdiff and interdiff very useful!
(also bash_goodies below have compare-latest which brings comparison
between two latest present builds, which come handy). Having debian
custom patches under debian/patches is a huge relief when some of the
changes propagate upstream (especially whenever with some modifications
introduced) -- you have simply to remove the patch instead of going
through the code and trying to figure out if a specific part was
due to the given 'patch'.

To help navigate between different packaging projects, and to simplify
the builds I hacked some bash helpers which are available online:

Brief description:

s-b-p         -- builds package under pbuilder (default to sid)
s-b-e         -- svn-buildpackage --svn-export and jumps into that
totrunk       -- copies changes over to trunk/
difftrunk     -- difference between current directory content and trunk

jtr <PROJECT> -- jumps to trunk/ of specified project.
jpb <PROJECT> -- jumps to pbuilder results for the project
jba <PROJECT> -- jumps to build-area/
jbr <PROJECT> -- jumps to branches/

u-0           -- uscan --upstream-version 0  -- to force fetching of the
                 upstream sources using debian/watch information

queryrep filename -- queries (through ssh session) some local repository
        for .deb and .dsc for some filename*. Helpful when to provide urls
        to freshly built packages 
and others...

all j* commands mentioned above have completion over found PROJECTs, so
most of the time it is enough to type a first letter of the project to
get its name ;-)
without <PROJECT> they jump to corresponding directory of the current

with mergeWithUpstream I just type s-b-e, then do necessary
modifications (adjust patches), difftrunk, then (assuming that the
files are clean and all changes between current and trunk are relevant)
I do totrunk.


On Wed, 16 May 2007, Magnus Holmgren wrote:

> I try to keep all changes to upstream as a number of patches in 
> debian/patches. I've heard that restricting the .diff.gz to ./debian is a 
> Good Thing. The drawback is that the .diff.gz becomes more difficult to read, 
> with the diff of diffs and all, but once the source package is unpacked it's 
> much easier to get an overview of the changes the maintainer has made. You 
> know all that.

Yaroslav Halchenko
Research Assistant, Psychology Department, Rutgers-Newark
Student  Ph.D. @ CS Dept. NJIT
Office: (973) 353-5440x263 | FWD: 82823 | Fax: (973) 353-1171
        101 Warren Str, Smith Hall, Rm 4-105, Newark NJ 07102
WWW:     http://www.linkedin.com/in/yarik        

Reply to: