On Thu, Apr 01, 2021 at 01:40:06PM -0700, Russ Allbery wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index a21a510..2a2e364 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -972,11 +972,33 @@ repository where the Debian source
Ian Jackson writes:
> Package: debian-policy
> Version: 4.4.0.1
> Many packages' .dscs contain something like this:
> Source: bustle
> Version: 0.7.4-1
> Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]
> The semantics do not appearr to be documented in policy.
Hello,
On Wed 23 Oct 2019 at 08:16PM -07, Russ Allbery wrote:
> diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
> index 60edc82..c8f7f78 100644
> --- a/policy/ch-controlfields.rst
> +++ b/policy/ch-controlfields.rst
> @@ -973,11 +973,33 @@ repository where the Debian
Ansgar writes:
>> +In the case of Git, the value must have the following syntax::
>> +
>> + [ " -b " ] [ "[" "]" ]
> That should be " [" (including a leading space).
Yup, indeed, thanks!
> I suggest something like "If is not specified, it defaults to `.`
> (or `debian`; see
> +In the case of Git, the value must have the following syntax::
> +
> + [ " -b " ] [ "[" "]" ]
That should be " [" (including a leading space).
> +
> +where the portions enclosed in brackets are optional and the portions
> +enclosed in double quotes are literal strings.
Control: tags -1 patch
Ian Jackson writes:
> I found myself trying to implement what I had suggested earlier and
> ran up against the question of what to do about [ ] in optional
> values.
> I decided to use this regexp
> + $vcsgiturl =~ s/\s+\[[^][]*\]//g;
> (I need to strip the
On Mon, Jul 22, 2019 at 01:57:55PM +0200, Mattia Rizzolo wrote:
> I don't remember where this was discussed (quite in length actually),
> probably debina-qa@ or debian-devel@. It was then implemented in
> vcswatch (https://qa.debian.org/cgi-bin/vcswatch) and elsewhere.
> I'm positive a result of
Russ Allbery writes ("Re: Please document Haskell team style Vcs-Git sytax"):
> Yeah, this is a pretty good point, and it decreases the complexity of the
> syntax a fair bit. Ian, what do you think about making the extensibility
> model for any future thing be add another field?
I found myself
Jonathan Nieder writes:
> For command line options like "-b", I would be okay with following the
> same model as last time and using space as a source of extensibility
> (i.e., breaking compatibility). So for that I wouldn't want to use
> the bracket syntax.
> For future settings in the same
Russ Allbery wrote:
> If you want to do what vcswatch is doing (analyze the current code
> repository for Debian packaging for commits that haven't been uploaded),
> and the team is, like Haskell, using a single repository for all the
> packages, you need to be able to find that specific package
Jonathan Nieder writes:
> In Git, when you "git clone" a repository, that represents a single
> codebase. There is no parameter you can pass to "git clone" that
> tells it to clone just a subdirectory. So we aren't including the
> in Vcs-Git in order to determine what parameters to pass to
>
Hi,
Ian Jackson wrote:
> Russ Allbery writes:
>> So, maybe something like:
>>
>> -b [; = ...]
>>
>> to build off of what we already have? (With, obviously, a bunch of that
>> syntax marked as optional.) If we ban "=" in , we can allow for
>> to be optional but some other key/value pair
Ian Jackson writes:
> SGTM. We can specify that [ ] contains optional information. I guess
> that is why that syntax was chosen...
> Then critical information which *should* cause an old parser to fail
> can also be added.
> So the overall syntax is roughly
>[ " -b " ] [ " " ]
>
Russ Allbery writes ("Re: Bug#932696: Please document Haskell team style
Vcs-Git sytax [and 1 more messages]"):
> So, maybe something like:
>
> -b [; = ...]
>
> to build off of what we already have? (With, obviously, a bunch of that
> syntax marked as optio
Ian Jackson writes:
> Russ Allbery writes:
>> Sure, an extensible syntax sounds great. The problem is that we kind
>> of had one (Vcs-Git was a subset of a git checkout command line, which
>> allowed support of the -b option), but this (if I understand it
>> correctly) is a whole new type of
Russ Allbery writes ("Re: Bug#932696: Please document Haskell team style
Vcs-Git sytax [and 1 more messages]"):
> Sure, an extensible syntax sounds great. The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed suppo
On Sun, Jul 21, 2019 at 08:29:16PM -0700, Russ Allbery wrote:
> Sure, an extensible syntax sounds great. The problem is that we kind of
> had one (Vcs-Git was a subset of a git checkout command line, which
> allowed support of the -b option), but this (if I understand it correctly)
> is a whole
Ian Jackson writes:
> I wrote:
>> Many packages' .dscs contain something like this:
>> Source: bustle
>> Version: 0.7.4-1
>> Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]
>> The semantics do not appearr to be documented in policy.
> But I foolishly didn't
I wrote:
> Package: debian-policy
> Version: 4.4.0.1
>
> Many packages' .dscs contain something like this:
> Source: bustle
> Version: 0.7.4-1
> Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]
>
> The semantics do not appearr to be documented in policy.
But I
Package: debian-policy
Version: 4.4.0.1
Many packages' .dscs contain something like this:
Source: bustle
Version: 0.7.4-1
Vcs-Git: https://salsa.debian.org/haskell-team/DHG_packages.git [p/bustle]
The semantics do not appearr to be documented in policy.
Ian.
--
Ian JacksonThese
20 matches
Mail list logo
