On Mon, Oct 14, 2002 at 10:36:30PM -0400, Colin Walters wrote: > On Wed, 2002-10-09 at 14:13, Anthony Towns wrote: > > No, not really. *shrug* > Well, I don't really want to give up that easily. *shrug* > I am sure we can come to a rough consensus. ...in so far as agreeing that the differences aren't important, I'd suspect. In particular: > * aj format > Advantages: > - dpkg-source v2 would sort of be a "superset" of v1 > Disadvantages: > - Separate diffs would be a bit tricky to manipulate I don't agree with the latter, see below. > * walters format > Advantages: > - Fairly simple to understand > - Would support adding binary files to packages in all forms > Disadvantages: > - grepping through a package source would sometimes turn up hits in > debian/patches, if you weren't careful to exclude the debian/ dir. Personally, I think having all the diffs be outside the source tree is simpler to understand: then you have three things: some tarballs, some diffs, and a source tree that's the tarballs + the diffs, with no possibility of weird interactions. > Now, I think looking at diffs is going to be a very common operation. > It's something that will happen when you're upgrading a package to a new > upstream version, and if you want to add a patch. Anything that makes > that more difficult is a bad thing. $ dpkg-source --extract-diffs foo_1.2.3-3.diff.tar $ less foo-1.2.3-3-diffs/* All --extract-diffs needs to do is untar into a sensibly named directory, which is straightforward, and easily done with plain tar. Which makes it trivial for you to do it in a non-Debian environment if you want to port Debian's patches to your system. > Obviously it's not horrible to have > to unpack a tarball to a temporary directory, drop a file in there, then > repack it, but why go through all that trouble if you don't have to? $ cd foo-1.2.3-4 $ vi src/*.c $ rm src/*.py $ debian/rules build $ ./runme $ debian/rules clean $ dpkg-source --make-diff 'rewrite from python to C' --make-diff has a more complicated job. It needs to: * create an .orig directory * unpack all the .orig.tar.gz tarballs into it in the appropriate way * unpack the .diff.tar into a working directory * apply all the patches therein to the .orig directory * run diff -ur on the .orig tree and the working tree and save the output into the diff directory, with the comment included and the order to run them in noted * retar the .diff directory with the new file None of these are complicated or hard to implement, though. > And the "superset" thing isn't important from an implementation point of > view, and can actually be bad from a user point of view; we'd want the > two formats to be clearly distinguishable. I don't see any reason to clearly distinguish the formats, and if it is desirable, I don't think we're really doing it: the .orig.tar.gz names are the same, the .dsc name is the same, and we were going to have the native format be exactly the same. "Hey, look, it's different! See?!" isn't a benefit. 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.''
Attachment:
pgpclvN3_6mX1.pgp
Description: PGP signature