[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Git and tarballs

Le mercredi 6 juillet 2011 17:52:31, Wolodja Wentland a écrit :
> Bonjour Thomas,


> > 
> > 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 

> 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.

Reply to: