> >>...< > 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 -- 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 -- 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/20130607191130.gh10...@onerussian.com
