Simon Huggins wrote on 29/01/2008 02:51: [wig&pen]
The meta data can easily be in these version control systems that everyone on these threads seems to love so much. If you want to keep more patches than you expose through wig&pen then just don't publish them in the dsc.
That won't work well for one of the packages I (co-)maintain (and I assume for some other packages, too): I want a patch to be included in the Debian source, since it implements an often requested feature, but it can break other things. In other words: It conflicts with another patch (or maybe even two), but I want somebody who does apt-get source on the package to be able to do a (trivial) modification to the unpacked source and rebuild the package to have that feature (though knowing that this breaks something else).
I think all Debian really needs is tools to generate a wig&pen source package and the appropriate tools to then deal with it e.g. dak and sbuild updates.
But still, wig&pen looks nice to me. I could include the necessary patch files (and short docs on how to get alternative build working) in the debian.tar.gz instead of the .patches.tar.gz IIUIC and reach the same goal I mentioned above. If wig&pen supported a series file (quilt) or 00list file (dpatch) in the .patches.tar.gz archive, I wouldn't need to work around anything. I don't mind getting the patches applied during unpack of the source package as long as the tool that is able to generate the source package from that unpacked source has a way to find out that someone changed the source after all patches were applied and handling that in a sane way (e.g. creating and enlisting an addition patch in .patches.tar.gz).
On another note, I have a slight problem with the (other) proposal of using a (git/$DVCS) repository as the form of source package distribution. Mainly because I think this will usually add bloat. While developing/packaging, I often see intermediate commits which need to be heavily modified or even reverted to finally build the patch I wanted to get working. Though these commits are fine in the Repository, I wouldn't want to see all the intermediate steps in the source package.
cu, Sven
Attachment:
signature.asc
Description: OpenPGP digital signature