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

Re: RFS: lbzip2

On Tue, 7 Apr 2009, Paul Wise wrote:

Looks fine, uploaded.

Thank you.

There is one pedantic lintian complaint:

P: lbzip2 source: direct-changes-in-diff-but-no-patch-system Makefile and 1 more

I think I'd like to start using quilt or dpatch for my own good. I tried to do an interdiff -z between 0.14-1 and 0.15-1. It complained about rejected hunks and effectively I didn't get back anything useful. The problem was this:

1. The original Makefile in 0.14 contained -O3 in CFLAGS
2. The 0.14 diff.gz kind of "moved" CFLAGS from Makefile to debian/rules
3. In 0.15 the original Makefile contained -O2
4. The 0.15 diff.gz moved the (changed) CFLAGS to the (changed) debian/rules

0.14 --> 0.14-1
 |         |
 |         ?
 v         v
0.15 --> 0.15-1

The "delete CFLAGS from Makefile" parts of the diff.gz's in question were so different that interdiff couldn't handle them. (Or that's what I think.)

Can quilt or dpatch solve this? I mean, the logical interdiff would have been to show no changes in the upstream Makefile *between* 0.14-1 and 0.15-1, and show a change for debian/rules, which I could validate against the diff between upstream 0.14 and 0.15. As if I had two full source trees, one for 0.14-1 and one for 0.15-1, and ran a diff -u -r on them. (I recognize that the diff.gz's simply may not have enough information in them for such an interdiff.)

Do you know of a good tutorial or high level (possibly debian-specific) process description on quilt or dpatch, and how to use them together with a VCS, ie. storing the individual patches themselves in a VCS? (Please don't anybody start yelling GOOGLE at me, I'm asking if you can name such a tutorial off the top of your head. If not, I'll *continue* googling, ie. weeding out the chaff from the results.)

I just found [1], which is very helpful, but doesn't speak about storing the patches in a VCS. (It may be a heretic idea to store patches in a VCS.)

Is the following workflow advisable?

1. I keep the debian subdirectory for lbzip2 under a separate CVS module, eg. "lbzip2-debian".

2. Whenever I start to debianize a new upstream version of lbzip2, I unpack the orig tarball, rename the project root to lbzip2-X.YZ, change to it, and check out module "lbzip2-debian" as "debian"; so that the result will look like this:


3. I work on both the upstream source files and the debian control files with quilt. (Hopefully the CVS subdir doesn't bother quilt.) I start by trying to apply the previous patches. When I'm done, I commit, tag (eg. deb-0_15-1) and release the "debian" subdirectory.

4. I (re-)export the "debian" subdirectory, so that the result looks like this:


(Perhaps I can skip releasing and exporting the debian subdirectory with CVS if the next step is not bothered by the CVS subdirs.)

5. I run pdebuild and hope that it notices the debian/patches subdir and outputs something accordingly instead of one diff.gz.

So how do DD's do this? I figure I could just ship a debian subdir with upstream lbzip2 (or keep a parallel branch running), but my impression is that this was advised against somewhere. I'd like to treat upstream lbzip2 with no concern for debianization, and I'd like to treat the lbzip2 debian package as if I weren't the upstream uthor. Two hats.

I still have no idea how to get a direct diff between 0.14-1 and 0.15-1 without having both versions exracted. I could get a diff of patches with cvs -- but how useful is that? Can a human digest that?

Sorry for this long rant.

BTW, no need to update the date in debian/copyright for each release.
The copyright/license should be updated if there is any change though.

Finally a rule that makes packaging easier :) I guess I thought the act of "debianization" happened per version, not per software package.


[1] http://pkg-perl.alioth.debian.org/howto/quilt.html

Reply to: