Re: XS-Vcs-field
On Mon, 13 Nov 2006 17:31:32 +0100, Stefano Zacchiroli <zack@bononia.it> said:
> On dom, 2006-11-12 at 14:02 -0600, Manoj Srivastava wrote:
>> I suggest that we specify tow headers: and SCM specific header,
>> XS-Vcs-<NAME> where name is one keyword from a specified list (bzr,
>> cvs, svn, darcs, git, hf, or arch), and XS-VCS-Browse, which is a
>> plain old HTTP URL.
> I like this proposal and I will implement it (addressing other minor
> issues pointed out by #393462).
>> Coming back to what it would take to fully specify sources in an
>> arch archive so that users can download the sources, I think that
>> the best thing to use would be to provide a URL for a grab
>> file. The grab file has a syntax:
> I don't have objections (mainly because I don't know what a grab
> file is). More generally though I would like to know opinions about
> whether it would be the case to describe in the developers reference
> what is the appropriate (non-browse) url for a given VCS. For
> example, would it be appropriate to document there that for arch a
> grab file should be used?
I think so. I can think of no other mechanism that would
allow complex arch setups to be downloaded in a supported manner
(simple single branch packages have alternate methods); and tla
already supports using grab files.
Arch, perhaps because it is a distributed SCM, and partially
because different people take ownership of different
segments in a large project, tends to encourage proliferation of
branches. A single project can be cobbled together from multiple
repositories/branches, with perhaps multiple alternatives for each
(this is in contrast with SVN, which does not really have a concept
of a package, but servers up whatever you put in, and so the top
level of a package can have everything -- much to a novices chagrin
:)
grab files can handle package/repo/branch mapping of arbitrary
complexity.
Debian packages tend to be especially suited for multiple
branches; since while most of the software is upstream, and is under
the control of the upstream author, ./debian directories are created
by the maintainer. A grab file works like an arch config file; it
helps stitch together a package from the components.
A grab file is also fairly static, and can be automatically
updated using arch hooks, scp, and a simple shell script (I already
have a hook function that updates the arch files whenever I commit
./debian; updating grab files is just an scp call away) .
All the ./debian directories in all my packages have far more
in common with each other than with the upstream sources they
package; and changes to one of my ./debian dirs, to, say, add
debsums, can be rapidly propagated to the sibling ./debian dirs; so
it makes sense for the ./debian dirs to be branches of a debian-dir
package.
Or take emacs. I have a ./debian dir that can take CVS emacs
and package it up for debian; but I can use the upstream mainline,
the unicode branch, the multi-tty branch (which is my current), Miles
Bader's branch, the lexbind branch, the tiling branch.
So, one can mix and match upstream and debian dirs (Romain
used to have his own emacs-snapshot debian-dir repo somewhere)
manoj
--
Xerox your lunch and file it under "sex offenders"!
Manoj Srivastava <srivasta@debian.org> <http://www.debian.org/~srivasta/>
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
Reply to: