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 [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.