Re: dpkg-source v2
On Tue, 2002-10-08 at 12:21, Anthony Towns wrote:
> grepping for a function that was patched out of existance, would show
> up as being present (as one of the - lines in a udiff), also.
I don't see this as a particularly high priority.
> No, not really. For a start, you *can't* create a .diff.tar with something
> as simple as "dpkg-source -b" -- that has no way of separating out the
> changes you've made into separate patches, and the separate patches
> you have in debian/patches don't exist.
Right.
> So, it's either a matter of
> constructing the source yourself (put the .orig's in place, tar up
> your patches put them in place), or having some tools that make the
> latter part easier for you (dpkg-source --unapply-patch, --apply-patch,
> --make-patch and --forget-patch, perhaps).
Hmmm...I personally can't see myself ever using this. However, if
people really clamor for it as a needed feature, we can always add it to
the v2 format later. That's one of the reasons I'd like to get
dpkg-source v2 into unstable as soon as possible; so we can figure out
how these ideas actually work in practice. I found a few issues with my
early prototype design just by repackaging the "hello" package. I'm
sure people with more complex packages will have more to offer.
> What dpkg-source -b *can* do is unpack the .orig's, apply the .diff's
> and generate a new patch of your changes to add to the .diff.tar (or,
> if you don't have a .diff.tar, to call a .diff.gz as it does now).
My current design is for to dpkg-source -b by default create a diff
named 00_debian.diff and drop it in debian/patches before creating
foo_debian.orig.tar.bz2.
> This seems like it would be especially nice for NMUs: all you need
> do is make sure there's a .diff.tar setup, then dpkg-source -b will
> automatically create a diff between the last maintainer release and
> whatever you upload, add it as the last patch, and probably call it
> something relatively predictable (which can then be checked when the
> source is uploaded, and even automatically filed in the BTS or mailed
> to the maintainer).
You could do that by simply generating a patch and dropping it into
debian/patches; e.g.
dpkg-source --patch --create > debian/patches/debian_nmu_aj_2002_10_09.patch
When a v2 package is uploaded, dinstall could even unpack the source
package, look at the source package for patches named debian_nmu_*, and
then automatically file them as bugs or mail them to the maintainer, as
you suggest.
> Having a .diff.tar isn't fundamentally different to debian/patches --
> it's essentially just a tarball of that directory, so there's not really
> any different complexity there, afaics.. The difference is where you
> expect the patches to be when the source is unpacked (applied, but
> otherwise out of sight), and how easy it is to get the patches (grab
> the diff tarball, untar it, poke around, instead of grab the .tgz, or
> the .orig.tgz or the _debian.orig.tgz and unpack it, and poke around,
> and maybe worry about symlinks to other .orig.tgz's, and, worst case,
> worry about patches that affect other patches that get applied later).
Getting the patches is as easy as untarring the debian.tar.bz2, and
looking in debian/patches. Also, I personally find it a bit ugly that
in your .diff.tar case, after I've unpacked a source, the patches aren't
in any easy-to-view place. I have to manually untar the .diff.tar,
etc. If a patch fails for some reason (say you're updating to a new
upstream version), this could quickly become a pain in the butt.
> YMMV, of course, but I think it makes sense to treat patches at the
> same level as the upstream source, rather than mixing it in with the
> packaging scripts, and such.
I hope that my above arguments have convinced you otherwise.
Reply to: