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

Re: Git and tarballs

On Wed, Jul 06, 2011 at 19:02 +0200, Thomas Preud'homme wrote:

> 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

[ snip ]

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

Ok based on this discussion and some great help on #debian-mentors I can now
think of the following workflows. I would sincerely appreciate any comments on
their merits and problems from people who have more experience than me. (i.e.
almost all of you).

The main desiderata are:

* Intuitive setup that follow the principle of least surprise
* debcheckout + git-buildpackage should work out of the box
* Easy
* Not much work for new upstream releases
* Flexibel if something goes boink and adaptations are needed
* Integrates well with existing infrastructure (github, alioth, commit hooks
  that push news to IRC channels or mailing lists, ...)



Name                    Local/Remote    Merges From             Tracks
master                  local           upstream                alioth/master
upstream                local           real_upstream/master    alioth/upstream
real_upstream/master    remote          n/a
alioth/master           remote          n/a
alioth/upstream         remote          n/a


Essentially tags are merged from real_upstream/master into upstream and
debian. The debian branch also contains the debian packaging and is the branch
from which Debian releases are cut. Packages are built with git-buildpackage
and the orig tarball is automagically created with "git archive" from a tag.


* How to differentiate between upstream and packaging history?
  → git-dch will be flooded with real_upstream changelogs (Or?)
* How to make sure that Charles Plessy is happy? 
  (i.e. commit-hooks do not flood channels with upstream changelogs)
* I know how to download tags from github with githubredir, but how to handle
  repositories elsewhere? (in debian/watch)

Git only - Repackaging

Essentially the same as before, but with an additional dfsg_free branch that
merges from upstream and is merged into master.

My main questions here are due to my wish to see repacking done in an
automated way by a script which is used in get-orig-source. 

* Where do you put those scripts? 
* What to do in the case of NMUs for new versions, such that the
  script is not applicable anymore and get-orig-version is essentially useless?
* Are there collections of these scripts somewhere?
  I can think of "jh_repack" right now, but are there other helpers? 
* What uses get-orig-version? 

Tarball only


Name                    Local/Remote    Merges From     Tracks
master                  local           n/a             alioth/master
upstream                local           n/a             alioth/upstream
pristine-tar            local           n/a             alioth/pristine-tar
alioth/master           remote          n/a
alioth/upstream         remote          n/a
altoth/pristine-tar     remote          n/a


Tarballs are downloaded from upstream and merged with git-import-orig, 
orig tarballs are constructed from upstream + pristine-tar.


* Is pristine-tar *really* needed here as it will basically say "No change from
  I have to confess that I don't quite see the merit of pristine-tar
  when generating tarballs as those should be exactly the same tarball
  as produced by "git archive TAG. Or am I missing something here?


I can easily see how the "git-only" workflow can also just be changed to use
"git-import-orig --uscan" which somehow feels like the right thing to do. What
to do though if new tarballs suddenly needs repacking?

In a way I have the feeling that the "tarball" only workflow is much better
suited for packaging, but something in me says that it is wrong as the
tarballs are not really needed because everything that is needed is already in
the VCS.

Sorry for the many questions -- I certainly owe all of you a dram of Talisker
when we meet ...
  .''`.     Wolodja Wentland    <babilen@gmail.com>
 : :'  :
 `. `'`     4096R/CAF14EFC
   `-       081C B7CD FF04 2BA9 94EA  36B2 8B7F 7D30 CAF1 4EFC

Attachment: signature.asc
Description: Digital signature

Reply to: