Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On November 12, 2014 8:15:02 AM CST, Scott Kitterman <debian@kitterman.com> wrote:
>On November 12, 2014 7:38:25 AM CST, Matthias Urlichs
><matthias@urlichs.de> wrote:
>>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.
>
>I don't think so. This is about what Debian as a whole
Oops.
... as a whole is doing. The DEP should be broad enough to capture at least rough consensus. Let's not make this in another poisonous us versus them issue. We have enough of those already.
Scott K
Reply to: