Re: dpkg-source v2
On Tue, Oct 08, 2002 at 12:52:50AM -0400, Colin Walters wrote:
>> Second, is that I'm inclined to think patches should be treated as a little
>> more first class, than having them secreted somewhere under debian/. The
>> theory being that you go "dpkg-source -x *.dsc" and end up with the complete,
>> patched source that you can then modify or grep or do whatever as appropriate,
>> without getting false positives thanks to the silly diff's lying about and
>> whatever.
> Hmmm...I don't understand this at all. dpkg-source -x will by default
> apply patches; that's one of the whole points of this endeavour :)
> What do you mean by false positives? Like grepping for a function that
> was patched would also show up something in debian/patches? That
> doesn't seem like a big deal to me.
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.
> > Packages with no upstream modifications:
> > foo_1.2.3.orig.tar.gz
> > foo_debian_1.2.3-1.orig.tar.gz
> > foo_1.2.3-1.dsc
> Hmmm. Again, I don't see what's wrong with having separate upstream
> modification patches in the debian tarball.
There's nothing /wrong/ with it.
> > Packages with one patch, including the debian/ stuff:
> > foo_1.2.3.orig.tar.gz
> > foo_1.2.3-1.diff.gz
> > foo_1.2.3-1.dsc
> So, doing this you would lose the ability to add binary files like .pngs
> to the package, which was another goal for dpkg-source v2.
Doing this, dpkg-source v2 becomes a superset of dpkg-source v1. I
don't necessarily think you'd want to have the tools use the above
format automatically.
> Also, you'd
> have to presumably have some way to tell dpkg-source -b to create a
> .diff.gz instead of a .debian.tar.bz2, which is just more complexity,
> for very little if any gain.
> > Packages with many patches:
> > foo_1.2.3.orig.tar.gz
> > foo_1.2.3-1.diff.tar.gz
> > foo_1.2.3-1.dsc
> And same here.
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).
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).
That is to say: dpkg-source -b can generate 1 or 0 diffs, no more; and
thus it can either *add* to an existing .diff.tar, create a new .diff.gz,
or create a new .orig.tar.gz (if there wasn't anything to diff against
to start with).
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).
And if there's no .diff.tar, and only a single .orig.tar.gz, it lets
dpkg-source -b automatically create a v1 compatible source for you.
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).
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.
Cheers,
aj
--
Anthony Towns <aj@humbug.org.au> <http://azure.humbug.org.au/~aj/>
I don't speak for anyone save myself. GPG signed mail preferred.
``If you don't do it now, you'll be one year older when you do.''
Reply to: