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

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. 


> 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

> 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: