Ian Jackson writes ("Re: Intent to commit craziness - source package 
> Guido Günther writes ("Re: Intent to commit craziness - source package 
> unpacking"):
> > 'gbp pq import' does have 'debian/patches' since it just puts the
> > patches that are in debian/patches on top of the unpatched source
> > tree. In contrast to your solution it doesn't try to be able to
> > roundtrip without changes for any given series on "gbp pq export". This
> > is only true if the series was also created by "gbp pq" (or adheres to
> > what git-format-patch does).
> Currently the output of dpkg-source --commit doesn't look much like
> the output of git-format-patch.
> I have tried to make dgit produce patches (when it needs to produce
> patches) that look like dpkg-source --commit.  But maybe it should
> produce patches using git-format-patch (or that look like
> git-format-patch).

I have looked at the specs (including DEP-3) and the behaviour of the
various tools a bit more.  I have decided that when I should replace
dgit's adhoc algorithm for generating a DEP-3 compliant commit
message, with a call to git-format-patch.  (The actual patch body has
to come from dpkg-soure, because of the special handling of debian/,
etc.  This code path is used when a dgit user is pushing and needs to
convert raw git commits into `3.0 (quilt)' patches.)

And, after having half-written a DEP-3 importer (ie a thing that turns
a DEP-3 patch message into a git commit), and investigating the
behaviour of various tools, I have decided I should just use gbp pq.
(This will replace the repeated use of dpkg-source --before-build as a
described in my previous mail.)

This will mean that dgit will grow a hard dependency on

Because I'm a pernickety type of person I reviewed the dependencies of
git-buildpackage.  I have some qualms about the following

  Recommends: pristine-tar (>= 0.5)

    pristine-tar has been declared unmaintainable by its original
    author and abandoned.

    IDK know what proportion of actual git trees that gbp users will
    encounter would break without pristine-tar.  Perhaps this
    dependency can be demoted to Suggests, but I don't really know.

    Certainly dgit users do not need pristine-tar.  But our dependency
    system does not allow us to honour only direct Recommends and not
    transitive ones.

  Recommends: cowbuilder                        <= jessie
  Recommends: cowbuilder | pbuilder | sbuild    <= sid

    Many users of dgit will never want to build a package for upload.
    This is probably true of gbp users too.  I'm not sure why it's
    valuable to have this as a Recommends dependency for gbp.

    I think more people now are using sbuild.  I'm not sure that
    pulling in cowbuilder on systems where the user has not yet
    installed such a tool is right.

  Depends: devscripts

    devscripts is very full of commands with poor namespacing.  It
    also has an enormous dependency chain.

    Unfortunately dgit has a dependency on devscripts too.  Maybe we
    should work to take the pieces of devscripts that we really need
    and put them in something else, or something.

Overall I don't think these are an impediment.  But since I had done
the review, I thought I'd share my thoughts.


Ian Jackson <ijack...@chiark.greenend.org.uk>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

vcs-pkg-discuss mailing list

Reply via email to