Bug#932696: Please document Haskell team style Vcs-Git sytax

[Mattia Rizzolo]

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 package is developed.
>  - Mtn (Monotone)
>  - Svn (Subversion)
>  
> -In the case of Git and Mercurial, the value consists of a URL,
> -optionally followed by the word ``-b`` and the name of a branch in
> -the indicated repository, following the syntax of the ``git clone``
> -or ``hg clone`` command. If no branch is specified, the packaging
> -should be on the default branch.
> +In the case of Git, the value must have the following syntax::
> +
> + [ " -b "  ] [ " ["  "]" ]
> +
> +where the portions enclosed in brackets are optional and the portions
> +enclosed in double quotes are literal strings.   indicates
> +the repository.  If the  stanza is present, it names a
> +branch in the indicated repository.  If no branch is specified, the
> +packaging should be on the default branch.  If the  stanza
> +is present, it specifies the relative path to the top of the packaging
> +tree (the parent directory of the ``debian`` directory).  If no path
> +is specified, it defaults to ``.`` (the top level of the indicated
> +repository and branch).
> +
> +For example::
> +
> +Vcs-Git: https://example.org/repo -b debian [p/package]
> +
> +indicates a subdirectory named ``p/package`` in the ``debian`` branch
> +of the repository at ``https://example.org/repo``.
> +
> +In the case of Mercurial, the value must have the following syntax::
> +
> + [ " -b "  ]
> +
> +This is interpreted the same way as the Git syntax except a path
> +within the repository is not supported.
>  
>  A package control file must not have more than one ``Vcs-``
>  field.  If the package is maintained in multiple version control


Seconded.

Thank you for formalizing this syntax.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
More about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

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.

Reminder that this proposed patch needs one more second to be merged into
the next release of Policy.

-- 
Russ Allbery (r...@debian.org)  

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 package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ " ["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it specifies the relative path to the top of the packaging
+tree (the parent directory of the ``debian`` directory).  If no path
+is specified, it defaults to ``.`` (the top level of the indicated
+repository and branch).
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multiple version control

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Sean Whitton]

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 source package is developed.
>  - Mtn (Monotone)
>  - Svn (Subversion)
>
> -In the case of Git and Mercurial, the value consists of a URL,
> -optionally followed by the word ``-b`` and the name of a branch in
> -the indicated repository, following the syntax of the ``git clone``
> -or ``hg clone`` command. If no branch is specified, the packaging
> -should be on the default branch.
> +In the case of Git, the value must have the following syntax::
> +
> + [ " -b "  ] [ " ["  "]" ]
> +
> +where the portions enclosed in brackets are optional and the portions
> +enclosed in double quotes are literal strings.   indicates
> +the repository.  If the  stanza is present, it names a
> +branch in the indicated repository.  If no branch is specified, the
> +packaging should be on the default branch.  If the  stanza
> +is present, it specifies the relative path to the top of the packaging
> +tree (the parent directory of the ``debian`` directory).  If no path
> +is specified, it defaults to ``.`` (the top level of the indicated
> +repository and branch).
> +
> +For example::
> +
> +Vcs-Git: https://example.org/repo -b debian [p/package]
> +
> +indicates a subdirectory named ``p/package`` in the ``debian`` branch
> +of the repository at ``https://example.org/repo``.
> +
> +In the case of Mercurial, the value must have the following syntax::
> +
> + [ " -b "  ]
> +
> +This is interpreted the same way as the Git syntax except a path
> +within the repository is not supported.
>
>  A package control file must not have more than one ``Vcs-``
>  field.  If the package is maintained in multple version control

Seconded, thanks.

-- 
Sean Whitton


signature.asc
Description: PGP signature

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

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 below)".

It's ``.`` (just now verified with the GHC repository).

Revised patch:

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 source package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ " ["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it specifies the relative path to the top of the packaging
+tree (the parent directory of the ``debian`` directory).  If no path
+is specified, it defaults to ``.`` (the top level of the indicated
+repository and branch).
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multple version control

-- 
Russ Allbery (r...@debian.org)  

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Ansgar]

> +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.   indicates
> +the repository.  If the  stanza is present, it names a
> +branch in the indicated repository.  If no branch is specified, the
> +packaging should be on the default branch.  If the  stanza
> +is present, it must be a relative path naming a subdirectory in that
> +repository and branch.  If no path is specified, the ``debian``
> +directory containing the packaging is expected to be at the top level
> +of the indicated repository and branch.

I suggest something like "If  is not specified, it defaults to `.`
(or `debian`; see below)".

> +
> +For example::
> +
> +Vcs-Git: https://example.org/repo -b debian [p/package]
> +
> +indicates a subdirectory named ``p/package`` in the ``debian`` branch
> +of the repository at ``https://example.org/repo``.

I don't understand what  does from just reading this.  When
`p/package` is given, which one of `p/package/debian/control` and
`p/package/control` is supposed to be used?

Ansgar

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

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 information, not use it.)  That hopes paths do
> not contain [ ] but permits (and eats) spaces inside the [ ].

> I'm inclined to think that these questions show that my original
> proposal was not brilliant and that your idea is better.

> HTH.

Here's proposed wording that documents only the already-in-use path
syntax.  (We're probably overdue for introducing ABNF into Policy so that
we can properly specify the syntax of things, but I didn't attempt to do
that here.)

Author: Russ Allbery 
Date:   Wed Oct 23 13:56:06 2019

Add support for paths in Vcs-Git

Closes: #932696

diff --git a/policy/ch-controlfields.rst b/policy/ch-controlfields.rst
index 60edc82..297f5c3 100644
--- a/policy/ch-controlfields.rst
+++ b/policy/ch-controlfields.rst
@@ -973,11 +973,33 @@ repository where the Debian source package is developed.
 - Mtn (Monotone)
 - Svn (Subversion)
 
-In the case of Git and Mercurial, the value consists of a URL,
-optionally followed by the word ``-b`` and the name of a branch in
-the indicated repository, following the syntax of the ``git clone``
-or ``hg clone`` command. If no branch is specified, the packaging
-should be on the default branch.
+In the case of Git, the value must have the following syntax::
+
+ [ " -b "  ] [ "["  "]" ]
+
+where the portions enclosed in brackets are optional and the portions
+enclosed in double quotes are literal strings.   indicates
+the repository.  If the  stanza is present, it names a
+branch in the indicated repository.  If no branch is specified, the
+packaging should be on the default branch.  If the  stanza
+is present, it must be a relative path naming a subdirectory in that
+repository and branch.  If no path is specified, the ``debian``
+directory containing the packaging is expected to be at the top level
+of the indicated repository and branch.
+
+For example::
+
+Vcs-Git: https://example.org/repo -b debian [p/package]
+
+indicates a subdirectory named ``p/package`` in the ``debian`` branch
+of the repository at ``https://example.org/repo``.
+
+In the case of Mercurial, the value must have the following syntax::
+
+ [ " -b "  ]
+
+This is interpreted the same way as the Git syntax except a path
+within the repository is not supported.
 
 A package control file must not have more than one ``Vcs-``
 field.  If the package is maintained in multple version control


-- 
Russ Allbery (r...@debian.org)  

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Clint Adams]

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 that discussion made clear there was no such
> URI format available already.

Do you mean https://lists.debian.org/debian-devel/2016/05/msg00368.html ?

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Ian Jackson]

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 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 information, not use it.)  That hopes paths do
not contain [ ] but permits (and eats) spaces inside the [ ].

I'm inclined to think that these questions show that my original
proposal was not brilliant and that your idea is better.

HTH.

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

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 spirit as  that don't involve
> command line options, or for command-line options that are okay to
> ignore, the

>   Vcs-Git-Whatsit: 

> approach should work okay.

> So I'm thinking the bracketed path might be enough here, without need
> for the additional complexity of in-field key/value pairs.

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?

-- 
Russ Allbery (r...@debian.org)   

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

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 in the
> repository to look for unreleased changes.

Thanks.  Once someone writes some proposed text, it seems like it would
be worth mentioning this kind of use case in it.

> Similarly, dgit presumably wants to be able to find the part of the
> repository that's used for packaging a specific package, and I assume Ian
> is thinking about doing some dark magic to make that work with the rest of
> dgit's workflow (although I don't know what that is, or how it would work
> with, e.g., dgit tagging).

*nod*

>> And similarly, what is the use case behind the other key/value pairs
>> described here?
>
> We don't know, but we've now had to add two different things we didn't
> anticipate, and so it seems like a reasonable assumption there may be
> more.

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 spirit as  that don't involve
command line options, or for command-line options that are okay to
ignore, the

  Vcs-Git-Whatsit: 

approach should work okay.

So I'm thinking the bracketed path might be enough here, without need
for the additional complexity of in-field key/value pairs.

[...]
> Being able to clone a subdirectory of a Git repository would be lovely,
> speaking as someone who works at a company that insists on using a
> monorepo.

Interesting.  That's helpful context.

>I think that's a pretty long-standing feature request, though.

No one's filed it at bugs.debian.org/git or https://crbug.com/git yet.
But there's a similar internal feature request at $DAYJOB.  Thanks for
indulging my questions.

Jonathan

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Russ Allbery]

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
> "git clone".

> Given that, what *are* we including the  for?

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 in the
repository to look for unreleased changes.

Similarly, dgit presumably wants to be able to find the part of the
repository that's used for packaging a specific package, and I assume Ian
is thinking about doing some dark magic to make that work with the rest of
dgit's workflow (although I don't know what that is, or how it would work
with, e.g., dgit tagging).

> And similarly, what is the use case behind the other key/value pairs
> described here?

We don't know, but we've now had to add two different things we didn't
anticipate, and so it seems like a reasonable assumption there may be
more.

> It's possible that it might make sense to use separate fields for this
> information --- e.g. a

>   Vcs-Git-Path: 

> or something like that.  That way, you get extensibility for free.

This is definitely true, and if I were paying more attention when this
first came up and had thought of it, I'd probably recommend that.  But I
think the water is already under the bridge since the bracket syntax is
already being used, and I'm not sure it's worth asking them to change
something that's already implemented in at least a couple of places.

> Alternatively, maybe there is a lurking Git feature request here, for
> example for an atomic view across multiple repositories, or for the
> ability to clone just a subdirectory of a repository (with
> https://crbug.com/git/2 you already almost have that, though it's fussy
> to set up sparse checkout to do it and you still have to "cd" into the
> subdirectory).

Being able to clone a subdirectory of a Git repository would be lovely,
speaking as someone who works at a company that insists on using a
monorepo.  I think that's a pretty long-standing feature request, though.

-- 
Russ Allbery (r...@debian.org)   

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Jonathan Nieder]

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 to be provided.
>
> SGTM.  We can specify that [ ] contains optional information.

Taking a step back, I'd like to understand the use case a little better.

In Subversion, it's standard to use paths to represent multiple projects
and even branches within a repository.  So in that setting, I completely
understand why  is part of the URL.

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
"git clone".

Given that, what *are* we including the  for?  And similarly,
what is the use case behind the other key/value pairs described here?

It's possible that it might make sense to use separate fields for this
information --- e.g. a

  Vcs-Git-Path: 

or something like that.  That way, you get extensibility for free.

Alternatively, maybe there is a lurking Git feature request here, for
example for an atomic view across multiple repositories, or for the
ability to clone just a subdirectory of a repository (with
https://crbug.com/git/2 you already almost have that, though it's
fussy to set up sparse checkout to do it and you still have to "cd"
into the subdirectory).

Curious,
Jonathan

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Russ Allbery]

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 "  ] [ " "  ]
>  [ " [" (  |  "="  "; " )* "]" ]

> We can say that it's  if it has "=" before any "/".  Then paths
> containing = are expressable as ./foo=bar

This is a little more complicated than I'd like (we have a few too many
different ad hoc parsers and novel grammars in Debian), but I think it's
unavoidable at this point without breaking backward compatibility in ways
that aren't worth it.

So, looks good to me.  Next step is for someone to get a chance to write
the language.  (I'll tag the bug accordingly.)

-- 
Russ Allbery (r...@debian.org)   

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Ian Jackson]

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 optional.)  If we ban "=" in , we can allow for
>  to be optional but some other key/value pair to be provided.

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 "  ] [ " "  ]
 [ " [" (  |  "="  "; " )* "]" ]

We can say that it's  if it has "=" before any "/".  Then paths
containing = are expressable as ./foo=bar

Ian.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Russ Allbery]

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 thing that I don't think corresponds
>> to any git command-line flags.

> By "extensible" I meant "new information can be added in a way that
> will be ingored by existing parsers".

Oh, I see.

So the idea is that normally the results will be "good enough" if the
additional information is ignored.  Yeah, I think that can work as long as
the extensibility is reserved for more accurate location of the right
packaging information and not for something more fundamental.  (Which
probably just means saying explicitly that authors of future extensions
should anticipate what happens if existing code just ignores the extension
and ensure that doesn't result in anything too terrible.)

Wedging extensibility into the existing format might be a little bit
weird, particularly if we don't want to break the Haskell convention (and
I assume we don't since there's already some software support).  I think
we're stuck with a bit of an ugly format since we also don't want to break
the current branch support, even though it would in retrospect make more
sense to use the same extensibility for the branch.

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 to be provided.

-- 
Russ Allbery (r...@debian.org)   

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Ian Jackson]

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 support of the -b option), but this (if I understand it correctly)
> is a whole new type of thing that I don't think corresponds to any git
> command-line flags.

By "extensible" I meant "new information can be added in a way that
will be ingored by existing parsers".

> It's kind of hard to design an extensible format with any well-defined
> meaning if we don't know what sorts of things people will want to add via
> extensions

That's why the syntax should have gaps as I describe above.

Ian.

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Mattia Rizzolo]

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 new type of thing that I don't think corresponds to any git
> command-line flags.
> 
> It's kind of hard to design an extensible format with any well-defined
> meaning if we don't know what sorts of things people will want to add via
> extensions
> 
> What we would ideally have is a git URL that allows representing the
> branch and path within the repository, along with the transport.  Surely
> there must be prior work out there -- has anyone defined such a thing
> already?

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 that discussion made clear there was no such
URI format available already.

-- 
regards,
Mattia Rizzolo

GPG Key: 66AE 2B4A FCCF 3F52 DA18  4D18 4B04 3FCD B944 4540  .''`.
more about me:  https://mapreri.org : :'  :
Launchpad user: https://launchpad.net/~mapreri  `. `'`
Debian QA page: https://qa.debian.org/developer.php?login=mattia  `-


signature.asc
Description: PGP signature

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Russ Allbery]

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 even CC the Haskell team!  Sorry.

> Haskell folks, would you care to suggest a wording ?

> Policy folks: can I suggest that we should define an extensible
> syntax ?  If the syntax had been made extensible last time it was
> extended, devscripts and dgit would probably have coped here.
> (#932697 in devscripts and #932699 in dgit.)

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 thing that I don't think corresponds to any git
command-line flags.

It's kind of hard to design an extensible format with any well-defined
meaning if we don't know what sorts of things people will want to add via
extensions

What we would ideally have is a git URL that allows representing the
branch and path within the repository, along with the transport.  Surely
there must be prior work out there -- has anyone defined such a thing
already?  https isn't going to cut it, unfortunately, since a lot of the
information we want to represent isn't part of the https URL to the Git
repository itself.  Subversion was closer to getting this right, although
made easier by Subversion's repository structure.

-- 
Russ Allbery (r...@debian.org)   

Bug#932696: Please document Haskell team style Vcs-Git sytax [and 1 more messages]

[Ian Jackson]

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 foolishly didn't even CC the Haskell team!  Sorry.

Haskell folks, would you care to suggest a wording ?

Policy folks: can I suggest that we should define an extensible
syntax ?  If the syntax had been made extensible last time it was
extended, devscripts and dgit would probably have coped here.
(#932697 in devscripts and #932699 in dgit.)

Ia.

-- 
Ian JacksonThese opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Bug#932696: Please document Haskell team style Vcs-Git sytax

[Ian Jackson]

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 opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.