Re: [PATCH] proposed v3 source format using .git.tar.gz
Ian Jackson wrote:
Manoj Srivastava writes ("Re: [PATCH] proposed v3 source format using .git.tar.gz"):
What exactly is the goal of this dpkg addition?
This is a sensible question to ask. Goals I would suggest:
I find myself wondering the same thing. It seems to me that one of the
main functions that the debian source format fulfills is essentially
that of a version control system. It allows multiple versions to
coexist in the archive, provides a change log to track the history, has
tools to examine changes across revisions in detail ( debdiff ), and so
on. While less refined than VCS like git, svn, et al, the debian source
format does manage to provide the core functions of a VCS.
Therefore, I ask, why would you pack one VCS ( git ) inside another (
deb src )?
* Enable all people who work with a Debian source package to do so
with the benefits of the distributed revision control system in use,
which includes smart merging, and so forth;
* Specifically, to enable the above for NMUers in such a way that
a minimum of additional work is needed by the maintainer to merge
* Abolish dpatch (and similar excresences) and specifically to get
back to the point where a Debian source package can be unpacked to
the point of seeing the source code without having to execute any of
* Make life easier for derived distributions by making it possible for
them to merge from us, and us from them, using all of the usual
features of the RCSs in use.
* Make it possible (once more) for NMUers to make a change to a
package without having to learn and interact with a revision control
system, even if the maintainers are using one. Ie, make it possible
to acquire the source, inspect it, edit it, build it, test it, and
upload it, using only tools which either do not depend on the RCS or
which entirely hide it, without disrupting or being disrupted by the
revision control system.
* When an RCS-agnostic NMUer has done their work, still give the
benefit of the RCS to the maintainer (and others) when merging the
This is a nice set of goals, and if we are ok with leaving behind the
current source package format to achieve this, then it seems to me that
using git ( or possibly another VCS ) is a good way to do this, but if
you are going to use git, then _really_ use it. Convert the archive
over into a bunch of git repositories - one for each package, and be
done with it. Why go into it half assed by packaging git inside the old