[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Introducing dgit - git integration with the Debian archive


On Fri, 23 Aug 2013, Ian Jackson wrote:
> The thing that really bothers dgit is that it is not always possible
> to round trip a tree through dpkg-source.  (And the case where it
> doesn't work is the common one.)
> That is, if I do this:
>   1. dpkg-source -x
>   2. edit things 
>   3. dpkg-source -b
>   4. dpkg-source -x on the output from stage 3
> then the output of step 4 is not always the same as the input
> to step 3.  Typically the output of step 4 has additional metadata
> files inside the tree.

Well, by default step 3 fails if you have upstream changes. Unless you
use --auto-commit or --single-debian-patch. So the logical thing to do
is to call "dpkg-source --commit . <patch-name>" when you know that you
have upstream changes compared to the last debian package.

I believe that after the --commit you have the same metadata that you
would have after step 4.

> For some more sophisticated workflow, it is necessary to round trip
> the patch stack through the archive and back into git.

I'm not following you here. Can you elaborate ? ("round-trip through the
archive" doesn't mean anything obvious to me)

What I would like to have with "3.0 (quilt)" source packages is a git
repository with the patches applied but without the .pc/ quilt dir (that's
just noise). We would probably have a debian/source/local-options to
indicate to dpkg-source that the patches are already applied and that
it should deal with it.

Then I add commits like usual and they would be automatically
converted to new quilt patches in a later step when I tell dgit
to build the source. (Bonus point: we could add some metadata
in commit notices to merge the change in a existing quilt patch)

The really tricky part is how to update the patches when you merge
a new upstream version that changes the underlying code so that the
patches no longer apply. See http://bugs.debian.org/572204 for how Colin
Watson deals with this. I think he uses bzr and I'm not sure if we
can force git to proceed with the merge if we have local uncommitted

Basically, it would be good enough I believe if we can approximate this
1/ a commit that reverts the Debian patches
2/ a commit that merges the upstream changes + reapplies Debian patches
   (git merge --no-commit + quilt push -a with the required human fixes)
   Bonus point if your replace the "quilt push -a" with git cherry-pick of
   all patches and automatic refresh of the patches.

> > BTW, instead of advising against "3.0 (quilt)" you should rather recommend
> > the usage of the --single-debian-patch option when using that format...
> > this will make it mostly work like "1.0".
> This is a command-line option ?  How does one specify in the source
> package that this is to be used.

You put "single-debian-patch" in debian/source/local-options (or …/options
if you want to keep it in the generated source package).

(=> with "local-options" this is another case of something that you can
have in your tree and that you won't have in the unpack of the generated
source package)

> > - what/who creates the initial repository? and what/who keeps it in sync with
> >   the (non-dgit-based) archive uploads?
> The repos are created only by dgit users.  Different dgit users see
> the same commits from the archive: the synthesised commits are
> deterministic.

OK, assuming that they are created on top of the same commit I guess.

Are those commits replacing all the files or are they actually a merge of
changes from upload_n-1 to upload_n in the git repository?

Raphaël Hertzog ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ http://debian-handbook.info/get/

Reply to: