[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#391023: 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

        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

        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)


Boys will be boys, and so will a lot of middle-aged men. Kin Hubbard
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: