Bug#706060: [packaging] Re: Bug#706060: so how is ITP going?
> >>All fair questions! We are following the practice we use for
> >>publishing PPA packages, which after installing building
> >>dependencies (git debhelper build-essential autotools-dev devscripts
> >>golang), boils down to:
> >>git clone git://github.com/dotcloud/docker; cd
> >>docker/packaging/debian; make debian
> >>That will take care of generating all packaging files. For the PPA,
> >>that's enough. Launchpad builders will take it from there. As you
> >>point out, this is not quite the process debian uses. We have
> >>already access rights and the next step is creating the proper repo.
> >>Upstream is meant to have /packaging/debian as we highly prefer to
> >>keep the root level clean and organized ( having /debian will
> >>suggest we could have /ubuntu
> >>/redhat /arch. It's much cleaner to have /packaging for packaging stuff :)
> >I hear you! I do...
> >but there are few "problems" with such an approach which would
> >keep such package at least "non-conventional" in Debian land:
> >- ideally Debian source package should not contain "generated"
> > files but rather sources ... including the content of debian/ directory.
> > the reason is simple -- maintenance of debian/ content.
> > if someone introduces fixes and uploads via
> > non-maintainer uploads, most probably those changes would be under
> > debian/ and if debian/ itself is "derived" from some other location --
> > it might get messy quickly
> >- people who 'debcheckout' (via Vcs- header fields in debian/control)
> > expect getting some repository (possibly a branch) where debian/
> > directory is already there so they could quickly tune it up and build
> > package right away, e.g. via
> > dpkg-buildpackage
> > which is the standard way to build a debian package out of extracted
> > sources (the actual standard is to e.g. call debian/rules binary
> > -- to generate binary packages)
> >with original debian packaging residing somewhere under packaging/ --
> >things would get... non-standard to say the least. It should not
> >preclude upload to Debian proper, since Debian policy doesn't mandate
> >original VCS structure, but the fact would be that contribution by
> >debian community could be hindered...
> >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.
--
Yaroslav O. Halchenko, Ph.D.
http://neuro.debian.net http://www.pymvpa.org http://www.fail2ban.org
Senior Research Associate, Psychological and Brain Sciences Dept.
Dartmouth College, 419 Moore Hall, Hinman Box 6207, Hanover, NH 03755
Phone: +1 (603) 646-9834 Fax: +1 (603) 646-1419
WWW: http://www.linkedin.com/in/yarik
Reply to: