Thank you for sharing all this wealth of information, Yaroslav. I've got
to admit I was a little confused about so many different ways to go
about packaging, until you mention git-buildpackage and I saw you are
using it on https://github.com/PyMVPA/PyMVPA . Thank you so much for
pointing that out!
The other side of packaging docker has been understanding how to do
proper packaging of go libraries. Michael Stapelberg has done an amazing
job in this area and together we currently reviewing the first docker
library dependency for an unstable release:
http://mentors.debian.net/package/golang-mux-dev
http://anonscm.debian.org/gitweb/?p=collab-maint/golang-mux-dev.git;a=summary
So, it looks that now we are on firm track to release docker in a no
distant moment.
On 06/17/2013 11:45 AM, Yaroslav Halchenko wrote:
FWIW -- just to share alternative ways -- it is common to go with
branches, i.e. I keep debian branch which adds debian/ directory with
packaging on top of "master"/releases content. That has pros and cons too
- pros: anyone could debcheckout (branch could be specified in vcs-git)
and adjust packaging, build package right away
it becomes clearer what was the released into Debian-land state of
things (by last merge from master)
- cons: if releases come from release branches (and not from a single
branch like master, or "releases") then merging into 'debian' branch
could be tricky and requires some trickery (I usually create
"releases" branch which "merge theirs" releases to be packaged)...
alternative resolution here could also be to have 'debian' branch as an
overlay -- containing just debian/ directory, and then use
git-buildpackage with overlay option (and specify that in
debian/gbp.conf). That one would happily overlay it on top of any
given branch/tarball and everyone would be happy... cons -- working with
such detached branch might be trickier too
just my .1c whatever they are worth
Thank you Yaroslav for sharing! I am curious to explore these
alternatives. Could you point us to a few projects to see these in
action?
btw - 1 more point why eventually you would need to branch anyways.
E.g. if some version in Debian stable would need to be fixed -- so you
would need to get back to that point and branch off
1. debian (or alike) branch with merges of the main code branch
a. where all releases come from 'master' branch so merging into
debian branch becomes easy -- examples are numerous, but let me point
to our own project:
https://github.com/PyMVPA/PyMVPA/tree/dist/debian/proper/sid
so here we named branch not simply "debian" but rather
"dist/debian/proper/sid", since we might also need to upload bug fix
package releases to debian stable, and then it would become
"dist/debian/proper/wheezy".
'proper' was there because we thought we might need a special branch
for neurodebian repository backports (http://neuro.debian.net/) but
that never got to be the case (we ship patches for backporting within
the same dist/debian/proper/sid under debian/patches)
b. if releases come from "release branches", so merging into "debian"
branch becomes tricky, I created 'releases' branch for sklearn
http://github.com/yarikoptic/scikit-learn
for merges into "releases" branch I use following git alias
# To overcome absence of "ours" strategy in git merge
mtheirs = !sh -c 'git merge -s ours --no-commit $1&& git read-tree -m -u
"$1"' -
so I do smth like
git checkout releases
git mtheirs RELEASE-TAG
git checkout debian
git merge releases
note that you can always got from a. to more complicated b.
2. debian branch carries only debian/ directory
well -- there is a lot of "debian packaging" projects which use this strategy,
and usually they are still under SVN... here might be an example on how it
would look
http://anonscm.debian.org/gitweb/?p=pkg-exppsy/python-traits4.git
but probably it is not the convenient one for your case.
--
To UNSUBSCRIBE, email to debian-wnpp-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: http://lists.debian.org/51dca0a9.8010...@dotcloud.com
