Hi, Simon McVittie: > Is it the intention of this DEP to mandate the gbp-pq-like repo > structure, which basically forbids use of tools whose design does not > match that? Or is the intention to set some conventions that can be true > regardless of whether you are using a more gbp-pq-like or more > git-dpm-like workflow, in the knowledge that that necessarily makes > those conventions less strict? > IMHO there are two basic approaches which are mostly at odds with each other.
One: Treat Upstream's git repository as Source Code; if upstream doesn't have one, pretend that it does by importing their tarballs. Use "git rm" to remove nondistributable files and generated stuff (if Upstream even includes them, which if they use git they hopefully don't). Apply Debian changes, packaging or not, to a packaging branch. debian/patches is an auto-generated packaging artefact which I as a maintainer can basically ignore. Other distributions may share the common repository. Call this one "integrated". Two: Treat Upstream tarballs as Source Code; if Upstream generates them from git-or-whatever, that's not our problem. Use a script to mangle the upstream tarball if it contains nondistributable files. Keep autogenerated Makefiles et al. around. Keep Debian packaging completely separate (in a different branch, or even in a diffferent archive) and use a quilt-ish workflow which treats the content of debian/patches as first-class citizens. There's not much point for other distros to share our packaging repository, so why plan for it? Let's call this one "divided". This DEP describes an integrated workflow. This DEP does not say anything about any sort of divided workflow, other than to implicitly (un?intentionally?) discourage its use by omission. I personally happen to like an integrated workflow, to the point that the first thing I do when working on anything packaged in a divided way I'll run a script that unwraps debian/patches into my upstream archive clone's debian branch. Based on a couple of reactions here, some from people who dislike integrated workflow at least as intensely as I don't, IMHO there's not much common ground between the integrated- and the divided- workflow adherents. Thus, please don't try to shoehorn a divided workflow into this DEP. Write your own. -- -- Matthias Urlichs
signature.asc
Description: Digital signature
