Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)
Steve Langasek writes ("Re: Status of dgit (good for NMUs and fast-forwarding Debian branches)"):
> On Tue, Sep 17, 2013 at 07:19:22PM +0100, Ian Jackson wrote:
> > TBPH I think it's a bug if build followed by clean doesn't restore the
> > package to the state you got out of dpkg-source. I don't want to
> > argue that as a policy change right now, but I don't have much
> > interest in adding code to dgit to better support the maintainers of
> > packages which are broken in this way.
>
> My understanding is that the current policy implies that the 'dpkg-source -x'
> -> './debian/rules clean' -> 'dpkg-source -b' round-trip should be
> idempotent for all practical purposes,
Yes.
> just as the './debian/rules build' ->
> './debian/rules clean' round-trip should be. So if ./debian/rules clean
> does something to a checkout of your branch, then that branch seems not to
> be a complete representation of the source package.
However, it appears from the rest of the thread that dpkg-source has a
hack in it which stops it recording the deletion of files, so that the
"dpkg-source -b" step edits the source on the way into the package.
There will be packages that rely on this.
> There are various reasons this might be the case - for instance,
> autogenerated autotools output that you want shipped in the source package
> but don't store in the repository - but these all still amount to imperfect
> representations of the source package, and dgit shouldn't cater to them.
> Either debian/rules clean should be fixed to not leave droppings, or if the
> output is not 'droppings', it should be part of the VCS history.
Well, I agree.
But ultimately I think what we're missing in this conversation is a
key underlying goal of dgit's design:
dgit is designed so that there is a single same coherent workflow for
NMUers and downstreams; and with that workflow supporting use of git's
source code management facilities (notably git reset and git clean).
The resulting design principles are:
* You should be able to work on a package without needing to
understand the maintainer's workflow.
* Every change to the source code (as represented by the Debian
package) should be done via git.
* Changes to the working tree should be managed with git as far as
possible.
* dgit should provide its user with convenient workarounds for
bugs and craziness in package build systems and dpkg-source.
* dgit's output, as seen by non-dgit users, should be compliant with
Debian's policies and processes, and tolerable to maintainers, but
not necessarily any better than that.
So to mention two of those convenient workarounds:
* The dgit user can trivially cope with packages which edit their own
source code, or delete bits of it, during build or clean. git
reset or checkout will sort that out for you.
* The dgit user can trivially cope with packages whose rules/clean
target is buggy. During work, you specify -wg to use git clean
rather than rules clean. For the release you use "dgit -wg
sbuild", which arranges that the tree you are using will be
subjected to git clean rather than rules/clean. The use of sbuild
means you don't care about damage done to the source by the binary
package build, and if you're not using sbuild you can use git reset
and git clean after dgit -wg sbuild to undo whatever the build may
have done.
Convenience for maintainers' use of dgit is a secondary goal.
In particular, it is a secondary goal that the dgit git history should
be the same as upstream's or the maintainer's git history. If the
maintainer's git trees are different to the source packages, and
therefore not useful for dgit, then the maintainer is inconvenienced
by not being able to use dgit; but all dgit's users can remain in
blissful ignorance.
Of course I am of the view that the correct contents of the git repo
and of the source package are the same. A maintainer who agrees with
this view will find that dgit helps support their workflow.
If this limitation leads to rejection of dgit amongst maintainers
whose workflows and source code management practices are less than
ideal, then that's acceptable, because dgit's usefulness doesn't
depend on adoption by maintainers.
That's not to say that there aren't things that dgit needs to do
better. In particular, there isn't currently good enough support for
maintaining a patch series for your package _in git_.
Ian.
Reply to: