[Neurodebian-devel] [Neurodebian-upstream] Debian package for mpi4py

[Yaroslav Halchenko]

On Fri, 03 Dec 2010, Yury V. Zaytsev wrote:
> Of course I wouldn't object if you can create a basic debian folder ;-),
> but what I actually meant is the layout that you use for
> git-buildpackage. I am not quite sure where I should commit the debian
> folder I'll be working on.
...
> zaytsev-guest 
you were granted the access so you should be able to mess up our
repositories now ;) everything looks fine?

> (I don't know why guest, actually, but it should not matter. I did send
> a join request.)

whenever you become a DD, you will get the one without -guest ;)


> I wonder if this way one will have to push -f (rebase the master) on
> each svn sync???
hm... you should never push -f

what you should:  never push to git changes in master before you "git
svn dcommit" them, which would commit to SVN, and then refetch them with
appropriate SVN information lines added to each commit msg, e.g.:

  git-svn-id: http://mpi4py.googlecode.com/svn/trunk@733 5d389830-dc4a-0410-848b-d77abd4f2261

that is why initial GIT commits would be different from the ones which
come back from SVN

> > from there -- spin off debian/ branch from the last release and initiate
> > packaging

> git checkout master
> git pull
> git checkout -b debian
> git-publish-branch

no need (although also no harm) to publish it before there is content in
it ;)

> <... add debian folder ...>
> git commit
> git push

now it is time:

git push --set-upstream origin debian


for many projects we complicate things a bit further: we keep

debian branch -- contains only debian/
  to initiate it starting off detached from master, this is the trick:

  git symbolic-ref HEAD refs/heads/debian
  rm .git/index
  git add debian/*
  git commit -m 'initial packaging'

debian-release -- integration branch -- just merges upstream's master and
  debian branches together, and that is what is considered as 'debian-branch' for
  git-buildpackage.

  to signal that I usually add debian/gbp.conf (e.g. [1]) which defines
  names for all those branches (upstream and debian)

[1] https://github.com/neurodebian/psychopy/blob/debian/debian/gbp.conf

> > So, altogether, basing your packages on a 'canonical' way -- tarballs
> > import -- would be the simplest to start with.
> So one has to import tarballs into git in addition to syncing with svn,
> right? Now I am completely confused how the two are playing together :-)

;-) that is where we often diverge from common practice of packaging from
upstream source distribution (tarballs).  We just do not use
them, and do not import into GIT.  I just rely on git-buildpackage generating me
.orig.tar.gz from the upstream's branch.

NB actually for fail2ban, I did use upstream tarballs as well, I had

  master -- comes from SVN
  upstream -- imported tarballs with corresponding merge points from master
  debian   -- pure debian/
  debian-release -- integration of upstream, debian + cherry-picked
              post-release commits from master (was before 3.0 (quilt) format 
              abundance :))


Sorry for the confusion.

For now we could simple initiate 'debian' branch based on master and do
not have all this 'debian-release' mess ;) or we could dump upstream's
SVN->GIT repository and just continue classical way with tarballs -- whatever
you feel more comfortable/worthwhile.

-- 
=------------------------------------------------------------------=
Keep in touch                                     www.onerussian.com
Yaroslav Halchenko                 www.ohloh.net/accounts/yarikoptic