Le mercredi 6 juillet 2011 17:52:31, Wolodja Wentland a écrit : > Bonjour Thomas, :) [SNIP] > > > > There was a thread recently about using tarballs or tags on > > debian-devel@l.d.o recently. No consensus was reached as it clearly > > depends on your needs and probably also your tastes. > > Yeah, TMTOWTDI is good and nice, but you are also often unsure what is good > and what not. Do you recall the subject of the thread? I skimmed through my > archive and nothing met my eye. No surprise. I had some difficulties myself and for good reason: the thread was about "Best practice for cleaning autotools-generated files". I would say the debate really started at [0] [0] http://lists.debian.org/debian-devel/2011/05/msg00420.html Only 2 people argued with each other about advantages and drawbacks of both solution but several interesting arguments were given along the long thread. Good luck for reading them. > > > Personally I work with upstream tarball. Yet, I do keep remote branches > > to follow upstream development in the same repository, but it's mainly > > for having convenient cherry-picks. Your setup greatly interest me. > > Yeah, this tarball-centric style seems to be quite typical. But after > playing around I found that the tarball is *only* needed to populate the > pristine-tar branch as everything else is already in the repositories. Absolutely. But you also need a branch with the content of the tarball. I also have example of tarball which doesn't contain the same thing as the upstream repo. Just consider all the tarballs which strip out all the repo-specific file (think .gitignore for example). Hence if you use the remote upstream dev branch you often need to repack so that the upstream branch match what was commited in pristine-tar branch. Actually I have the case of an archive which is pretty different from the upstream SVN repo. > > I just wasn't sure how repacking (with/without helpers) is handled. As you said, it's common practice to have a get-orig-source target in debian/rules which will remove all the necessary files. But I guess it might need some very regular update in some cases, for example if upstream code contains some non-free files which change from one version to another (like image for some theme). Note that I never experienced that and is pure speculation. [SNIP] > > Yeah, that is exactly the problem I am facing there and a major problem > with this approach. I guess that "upstream" should be used in the way > intended by git-buildpackage. If "real upstream" branches are needed they > can be added later and tracked locally under a different name. > (suggestions?) Personally I don't have any local branch, just remote branches. And when I need to do a bisect for example I will checkout temporarily one of the upstream dev branches. What I have is: origin => upstream repo alioth => alioth repo master, upstream and pristine-tar are also local branches. No local branches for origin. And I also maintain a branch per distribution (lenny, squeeze, wheezy, sid) on alioth only. I try to update them so that they always reflect the state of my package in the respective distributions. > > > > 2. How to repack tarballs/tags? (DFSG, etc) > > This question still interests me. Is this *really* done manually? How do, > for example, jh_repack (in the watchfile) and get-orig-source fit into the > picture? I think the best is to have a working get-orig-source and then just call uscan + debian/rules get-orig-source and pristine-tar commit the result. Of course you should check the result but the interesting thing about this setup is that people can reproduce the filtering themself when a new version is released and you didn't package it yet. > > Thanks for your input, that was quite helpful. I guess the one *very* > important aspect is that people should be able to "debcheckout foo" and > "git-buildpackage" and don't run into problems. You're welcome. Best regards. Thomas Preud'homme
Attachment:
signature.asc
Description: This is a digitally signed message part.