Hi Reinhard (and others), On Sat, Apr 03, 2010 at 10:04:11AM +0200, Reinhard Tartler wrote:
On Fri, Apr 02, 2010 at 20:59:02 (CEST), Jonas Smedegaard wrote:Jonas, perhaps you answer these questions: - do you commit the quilt control directory .pc/? - do you commit the tree with patches applied?- if not, is everyone expected to run 'quilt pop -a' before committing changes to the tree?So there is your answer to the questions: No - I commit unapplied patches, not applied ones or quilt noise!Hm, but requires additional manual overhead to make sure that you don't commit noise. Does this really make packaging easier then?
Sorry for the too short answer (thought I covered the details in my other mail fired off right before I saw tha above question) - let me try elaborate a bit more here too:
First it was claimed that git-buildpackage did not work with the new source format. I believe that to be untrue (and suspect it to be a rumor held alive by developers that have not actually tried, and perhaps misunderstood and blown out of proprtions info like that bugreport from Colin).
Here you raise the more relevant concern if the new format is beneficial or brings mors hassle.
I certainly believe it it beneficial (and from that bugreport I get the impression that Colin feel the same - it is just a _wishist_ bug and he introduces by higly prising the new format in general):
The distributed source is much easier to handle: a tarball of upstream source and another tarball of Debian source, rather than the latter being a diff - which in the case of changes to upstream source becomes convolutes diffs-inside-a-diff. some may not care, but personally I use Midnight Commander and frequently inspect source package contents by "browsing" it using the mc virtual filesystem feature, and here it is much more usable to browse actual files and diffs than diffs and diffs-of-diffs.
Upstream source can be redistributed as-is even when in bzip2 format. Some may not care. but I happen to prefer using pristine tarballs whenever possible, and work towards automated ways of validating such pristine sources when upstream publishes checksums of them - something which obviously is impossible when repackaging or even generating a custom tarball from upstream VCS source.
Build process need not be more hassle. Some may not care but I happen to _like_ switching back and forth between pristine source and source with patches applied. As I believe I wrote already in an earlier response, those wanting things as simple and automated as possible have several options:
1) request git-buildpackage to do the build in a separate directory to not mess with the Git tree 2) tell Git to ignore the .pc directory, and instead of invoking "debuild clean" instead invoke "debuild clean && quilt pop -a".
If 2) is the preferred way, but still too much hassle, I would be happy to help design a smapp debuild wrapper script that seemlessly a) removes .pc dir if only containing dotfiles, and b) unpatches whenever cleaning. I would not use such script myself, because (as I wrote above) I happen to use it as a feature, no matter if that was the intend of it :-)
I use git-buildpackage, not topgit!I don't understand this comment. Topgit managing each "change" as a branch (AFAIUI).
Ah, sorry again for being to short:At some point (last spring, I believe it was), I investigated Topgit as an alternative to git-buildpage. One of my concerns was that I would then loose control over the patches: With topgit patches are intended to be dynamically generated. What is tracked in the VCS is the applied patches, while the isolated patches are only autogenerated on demand and cannot properly be maintained in the VCS.
Oh well - this might very well be me not fully understanding the wonders of the Topgit appreach. I did not mean to expand the discussion here to include truths and rumors of Topgit - I just instinctively saw a parallel between the Topgit style and what seems to be your preferred style: Not track isolated patches in VCS but have them generated on-the-fly.
Perhaps you would be interested in gbp-pq, added recently to git-buildpackage.
More information here (as mentioned in its manpage): https://honk.sigxcpu.org/piki/development/debian_packages_in_git/
I have not used it myself (I am sceptical to the dynamic generation of patches) and suspect that it won't solve the noise with dpkg format 3.0, so just a side note...
Sorry, I still think this mode of operation is pretty silly. I'd much prefer if the patches were maintained by git-buildpackage as proper git commits instead of text files. Upon source package generation, these commits need to be exported as quilt patches of course. This way, updating to a new upstream version would use git's conflict resolution mechanisms instead of quilt (which can only merge 2-way, git can do a 3-way merge).I guess other VCS systems like hg or bzr at least try something in that directions (although I have to admit that I didn't follow the latest developments there).You are free to find git-buildpackage silly, and prefer different VCSes altogether.This is not what I said,
Whoops, you are right. Sorry! I was too quick on the keyboard there, writing before reading properly. :-/
You did not bash git-buildpackage in general but only its limited use of git merge (it is used in git-import-dsc and git-import-orig but not after that).
and granted, I shouldn't have used the word 'silly' but a less strong word.
Nah, that's ok. I just think I should've been less jumpy :-)
I think that Format 3.0 does not work well with git-buildpackage. At least, git-buildpackage should integrate more with dpkg so that unnecessary "commit noise" is avoided.
Am I free to not find it silly? As part of this team?I'd very much prefer to work on a consistent set of packages. Having some packages maintained in this and some in another way leads individuals to look and care only after a subset of our team's packages.
Hmm. Then perhaps I already do not fit in and should go solo again: I push the use of CDBS which already divides the packaging in two camps, and also have strong opinion on the use of pristine sources.
What do you think? What do others think? Kind regards, - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private
Description: Digital signature
_______________________________________________ pkg-multimedia-maintainers mailing list firstname.lastname@example.org http://lists.alioth.debian.org/mailman/listinfo/pkg-multimedia-maintainers