[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:
> > Well, by default step 3 fails if you have upstream changes.
> I'm not sure what you mean by "upstream changes".  Do you mean changes
> outside the Debian directory ?

Yes. This was discussed on debian-devel and it was considered to be a
better default behaviour.

Discussion starts at:

> If so I wasn't aware of it.  Perhaps I
> didn't read the manpage clearly enough.  I think that is also broken.
> It seems to me that the most basic requirement of an archive source
> format is that the four operations I describe above should work and

Well doing the right things with "3.0 (quilt)" means (for most people)
to keep the source package tree actually usable with quilt, so actually
recording "non-quilt managed" changes in a new quilt patch.

> Ie:
>  (i) dpkg-source -b should be able to run on any reasonable tree
>  (ii) dpkg-source -b should not modify the directory it is run in
>  (iii) dpkg-source -x should always produce the same tree as
>        was fed to dpkg-source -b
> But as I understand you, `3.0 (quilt)' violates these and this 
> deliberate.
> If I have understood you, dgit won't work properly if you make the
> "wrong" kind of change, so I need to either have this fixed, or (more
> likely) to work around it (and bitch some more in the manpage).  Does
> "dpkg-source --commit" make any changes other than to quilt metadata ?
> Perhaps dgit push should do that automatically.

dpkg-source --commit adds a new patch in debian/patches/, it adds the
corresponding quilt metadata, and it might also modify
debian/source/include-binaries in case you have (modified/new) binary
files that can't be represented in a quilt patch.

I agree that it should be called automatically before trying to build
the source package. At least for formats "2.0" and "3.0 (quilt)", it
doesn't fail with "1.0" but does nothing except spitting out a small
message “'dpkg-source --commit' is not supported by the source format

But you should be aware that it's an interactive command, it will ask for
the patch name (thought this can be avoided by feeding it on the command
line) and it will run sensible-editor to let the user edit the DEP-3
metadata on top of the generated patch.

OTOH, if you use --auto-commit, you get back to the old behaviour and
dpkg-source -b will work and create the new patch non-interactively.
(aka dpkg-buildpackage --source-option=--auto-commit -S)

> > 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)
> It seems to me that it is the maintainer who determines the source
> package format.  Therefore putting this in local-options makes no
> sense.

On the contrary, the maintainer uses a VCS based workflow and generates a
single patch on every upload. But then if someones does an NMU, you'd
rather have dpkg-source generate a separate patch instead of updating the
maintainer's monolothic patch. Putting it in local-options (in the git
repository) achieves exactly that.

> > 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?
> Each upload is represented as a new root commit whose tree contains
> the files which are the result of "dpkg-source -x".  This is then
> merged into the existing head of the suite's branch in dgit-repos with
> a pseudo-merge (ie, a merge which takes content only from one of the
> parents).  The dgit-repos suite branches are fast-forwarding.

And the content is taken from the parent which represents the uploads? So
basically you overwrite any other changes that might have been done since
the last upload? Otherwise there's no point in that pseudo-merge if it
doesn't grab the changes made by this upload.

So basically the difference with git-buildpackage is:
- the uploads are represented by pseudo-merges from root commits
  (whereas with git-import-dsc you get non-deterministic commits
  because they are made on top of the upstream branch with a varying
- you have a centralized repository for all packages
- you define some default branches that track the centralized repository
- you track in the source package the commit from which it has been

Are there any other important differences?

It seems to me that the value is really in the first feature because it
allows merges to stop at the first common upload available in the history
and thus work even though the repositories might sensibly differ.

The centralization is a nice bonus but the fact that it's required is
somewhat problematic, I don't see the point in duplicating data in another
git repository when all my packages are already using git (and often in
collab-maint so all DD have write access). It would be nice if it could
rely on the Vcs-Git fields available in the archive and then optionally
work on those repositories instead of dgit.debian.net.

Raphaël Hertzog ◈ Debian Developer

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

Reply to: