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