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:
lbzip2-0.15
lbzip2-0.15/debian
lbzip2-0.15/debian/CVS
lbzip2-0.15/debian/patches
lbzip2-0.15/debian/patches/CVS
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:
lbzip2-0.15
lbzip2-0.15/debian
lbzip2-0.15/debian/patches
(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.
Thanks!
lacos
[1] http://pkg-perl.alioth.debian.org/howto/quilt.html
Reply to: