Re: [PATCH] proposed v3 source format using .git.tar.gz
On Sun, 7 Oct 2007 12:24:46 -0400, Clint Adams <schizo@debian.org> said:
> On Sun, Oct 07, 2007 at 11:10:41AM -0500, Manoj Srivastava wrote:
>> Hmm. If I have just the ./{arch} directory, and none of the files,
>> then arch thinks the files have just been deleted; and you can't just
>> check out stuff, since the tree is up to date. Ah. Baz undo restores
>> all the files, cool.
> I presume you could ship all the "normal" files in one tarball, the
> .arch-ids and {arch} directories in another, and the debian/ directory
> in a third.
Err, and why am I doing this? Why am I not shipping my working
directory as a tarball, complete instead of breaking it up
(apparently arbitrarily) into three parts?
> That would give the NMUer a full working tree to run $TLA diff in.
> Only shipping a grab file would burden the end user with a need for
> http access and no guarantee that the source will be available.
How is git reconstituting the files if there is no network
access? Are they shipping all the bits needed to get a full working
dir without any network access?
>> The problem here is that the repository in question _has_ to be
>> registered by the user running this; so all the users would have to
>> register the arch repository in question before unpacking the source
>> tarball in order to tell baz/tla how to get access to the repo. Is
>> this going to be an issue?
> It shouldn't be too difficult to add an --autoregister switch to tla
> grab, though I don't know how safe it'd be.
caveat emptor, I think, given that some repository access seems
to be required for unpacking a version 3 source package. This is not
something I would do in an un-constrained environment.
manoj
--
It is impossible to make anything foolproof, because fools are so
ingenious.
Manoj Srivastava <srivasta@acm.org> <http://www.golden-gryphon.com/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: