On Mon, Oct 08, 2007 at 09:16:52AM -0500, Manoj Srivastava wrote:
> In any case, I think the kinds of actions taken by joey's and
> Colin's patches are probably not things that we'll have to do to
> support shipping an arh working directory in the source packagel if we
> have {arch} and .arch-id dirs in the source, the end user has access
> to the distributed version control system;
Joey's thing lets you do a clean tarball that only contains the git
(or bzr, or darcs) information, and recreates the working directory by
a checkout.
For CVS the equivalent would be shipping the CVSROOT, for rcs the
equivalent would be shipping only the ,v files. If you don't have git,
you can't do *anything* with a .git.tar.gz source package. If you unpack
it by hand, all you get is the .git directory -- no debian/control,
no debian/rules, nothing.
You could do something similar with darcs/git/bzr atm simply by shipping
the .git, _darcs or .bzr directories as part of your source package --
that's discouraged atm because it's duplicate information that bloats the
source package, but it's entirely possible -- some ifupdown uploads have
included the _darcs directory, eg.
Ultimately, it turns the source package into a snapshot of not just the
current codebase, but the history as well -- or in the case of a shallow
tree, the recent history.
What's the point of that?
There may not be any -- if you're just packaging something that's
completely straightforward, just adding a pointer to the official
repository is probably the most sensible thing to do anyway; whether
that be a subversion url or a tla grab file, or something else, and
you can already do that.
Where it starts becoming relevant (afaics) is when there's a
Debian-specific patch history (either due to it being a native package,
complicated packaging, or significant patches against upstream) and
we want the archive, as the primary way we distribute the source, to
include a real change history rather than a simple snapshot.
You can do that to some extent via all the dpatch tools, but they're
kludgy in various ways; having the source format allow for an actual
repository from a real VCS solves that in a really powerful way.
> I am not sure how the pritine-tar bit fits in into the picture
> yet.
I don't think it really does; though it makes it possible to confirm
that the point in the repo that claims to match some upstream release,
really does match the official tarball of that release from upstream,
which might have some use.
pristine-tar seems mostly useful for generating a v1 source package
purely from a remote repository; this allows you to turn a repository
_into_ a (v3) source package.
Cheers,
aj
Attachment:
signature.asc
Description: Digital signature