Hi Simon,
(Please CC me on these, I'm not currently subscribed to -devel, and I'm
catching up from the list archives. At the very least it will make it
easier to avoid accidentally breaking the threading :)
> 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.
>
> Simon said:
>
> 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?)
So in gitpkg, the repo itself is, for want of a better term, quite
simply WYSIWYG. I believe it's actually the simplest of all the
schemas here, since the idea is the repo simply contains the source
in the preferred form for modification.
If you happen to also be upstream, you check out the upstream branch
and modify it as per normal.
When you're ready to release, you merge the new upstream changes into
the debian branch, and then make any modification to it as per normal.
You don't need to build any tool-specific structure into what you put
into the repo for this to work. The diff between the debian branch
(or tags) and the upstream branch (or tags) at any relevant points
should be exactly equal to what you'd get in a format 1 diff.gz or
its equivalent for format 3 packages.
If you want to build a format 3 package with your upstream changes
broken out into debian/patches, then you simply enable the hook for
that, which automatically extracts the changes that are still
outstanding from upstream (just like the normal git-cherry function
would for feature branches forked from an upstream branch) and
creates the relevant debian/patches for you in the exported package.
The idea is, you *already* have those patches in the repo, in a form
which your upstream could trivially cherry pick when asked, or that
you could cherry pick into a "for-upstream" feature branch for them
to merge etc. (again just using the normal "non-debian" git workflow
for people submitting patches to an upstream reviewer for merging).
Duplicating them in the repo in some way just makes busy-work for
you to maintain that, bloats your repo unnecessarily, and adds an
extra point of failure if you make a mistake in keeping those copies
correctly synchronised.
So gitpkg recognises that this is something that is part of what
some people want in the exported package, and automates the task
of turning what is in the source repo into a Debian package in
the form that they want. Exporting a debian/patches that exactly
corresponds to the unmerged patches you still have is one of the
tools that it provides for making packages in the form that you
want them, without needing a repo that was "specially prepared"
for this purpose in advance, and locked into the idiosyncrasies
of some specific tool to be able to do it.
Does that make sense?
Cheers,
Ron
[On a slightly separate note I am also interested to hear more
about whatever the confusion was you had with this was when you
started working with Tollef's systemd repo that you mentioned
in the previous thread. AIUI at the time, it was just that
mbiebl was out of his comfort zone when typing git-buildpackage
on that repo didn't do what he expected (which seems more like
gbp's failing to me ;) If it was something more than that, I'm
curious to know about it though to see what needs to be improved
to avoid it]
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/20141112220708.ga10...@hex.shelbyville.oz
