Re: RFC: DEP-14: Recommended layout for Git packaging repositories
On 12/11/14 05:54, Mathieu Parent wrote:
> Also, the vendor/* branches heads should be at a descendent commit of
> the corresponding upstream branch, diffing only by the debian dir.
This is only true for workflows similar to the one normally used with
gbp-pq, in which desired patches are serialized into debian/patches/ by
an out-of-band step (e.g. gbp-pq export, or quilt), and the upstream
tree is unpatched.
In particular, it is not true for git-dpm, dgit, or (as far as I can
tell from Ron's description elsewhere in this thread) gitpkg; with those
workflows, upstream files in the Debian branch *do* have their desired
changes.
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?
(I use gbp-pq for non-native packages myself, but trying out git-dpm is
on my to-do list.)
Concrete example: suppose you maintain an implementation of "hello
world", with a Debian patch changing hello.c to say puts ("hello,
Debian") instead of puts ("hello, world").
In the gbp-pq world, after "git checkout debian/sid", hello.c would
contain "hello, world", but there would be a patch in debian/patches/ to
change it from "hello, world" to "hello, Debian".
In git-dpm, after "git checkout debian/sid", hello.c would contain
"hello, Debian", *and* there would be a patch in debian/patches/ to
change it from "hello, world" to "hello, Debian". AIUI, dgit also works
best in this arrangement (or might even require it?)
I'm not so sure about gitpkg - I *think* "git checkout debian/sid" in a
gitpkg repository would result in hello.c containing "hello, Debian",
and no patches in debian/patches. But I could be wrong. (Ron?)
S
Reply to: