Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.maint.java > #12257 > unrolled thread

packaging Go runtime for ANTLR4

Back to article view | Back to linux.debian.maint.java

Contents

  packaging Go runtime for ANTLR4 Peymaneh Nejad <p.nejad@posteo.de> - 2021-07-27 10:10 +0200
    Re: packaging Go runtime for ANTLR4 Olek Wojnar <olek@debian.org> - 2021-07-27 17:10 +0200
      Re: packaging Go runtime for ANTLR4 tony mancill <tmancill@debian.org> - 2021-07-27 18:10 +0200
    Re: packaging Go runtime for ANTLR4 Emmanuel Bourg <ebourg@apache.org> - 2021-07-28 10:10 +0200
      Re: packaging Go runtime for ANTLR4 Peymaneh Nejad <p.nejad@posteo.de> - 2021-07-28 11:20 +0200
      Re: packaging Go runtime for ANTLR4 tony mancill <tmancill@debian.org> - 2021-07-28 17:10 +0200
        Re: Re: packaging Go runtime for ANTLR4 Nilesh Patra <nilesh@debian.org> - 2021-07-28 21:40 +0200
          Re: packaging Go runtime for ANTLR4 tony mancill <tmancill@debian.org> - 2021-07-28 21:50 +0200
          Re: packaging Go runtime for ANTLR4 Andrius Merkys <merkys@debian.org> - 2021-07-29 09:10 +0200
            Re: packaging Go runtime for ANTLR4 Olek Wojnar <olek@debian.org> - 2021-07-29 16:20 +0200
            Re: packaging Go runtime for ANTLR4 Nilesh Patra <nilesh@debian.org> - 2021-07-29 21:50 +0200
            antlr 4.10 released [Was: Re: packaging Go runtime for ANTLR4] Andrius Merkys <merkys@debian.org> - 2022-04-13 10:40 +0200
          Re: packaging Go runtime for ANTLR4 Emmanuel Bourg <ebourg@apache.org> - 2021-07-30 02:40 +0200
        Re: packaging Go runtime for ANTLR4 Emmanuel Bourg <ebourg@apache.org> - 2021-07-30 05:50 +0200

#12257 — packaging Go runtime for ANTLR4

[Multipart message — attachments visible in raw view] — view raw

Hi,

I am working on some packages that require the Golang runtime for ANTLR4[1].

I saw that the antlr4 source[2] in the archives includes the 
libantlr4-runtime-java binary but that the Python and C++ runtimes are packaged 
in seperate sources.

Is it intended or wished for that additional runtimes other than Java are 
packaged in seperate source packages, or would it be better to add another 
binary package (that'd be golang-github-antlr-antlr4-dev) to the existing source?
For the latter case, I'd be happy to update the existing package and prepare a 
new release for experimental.

Please let me know what you think.

kind regards,
Peymaneh

PS: I'm not on this ML so please keep me in CC when answering ;)

[1] https://github.com/antlr/antlr4/runtime/Go/antlr
[2] https://tracker.debian.org/pkg/antlr4

[toc] | [next] | [standalone]

#12258

[Multipart message — attachments visible in raw view] — view raw

Hi Peymaneh,

On Tue, Jul 27, 2021, 04:09 Peymaneh Nejad <p.nejad@posteo.de> wrote:

>
> Is it intended or wished for that additional runtimes other than Java are
> packaged in seperate source packages, or would it be better to add another
> binary package (that'd be golang-github-antlr-antlr4-dev) to the existing
> source?
>

In principle, if the same source is used for all of the binaries, I feel
that we should maintain a single Debian source package. Unless there's some
compelling reason to split them.

I can't think of a good reason to split source but I can definitely think
of several good reasons to have a single source package! e.g. inter-binary
compatibility, security updates, etc.

-Olek

PS Your GitHub link was broken for me and I don't have time to look up the
source to verify my assumption.

[toc] | [prev] | [next] | [standalone]

#12259

[Multipart message — attachments visible in raw view] — view raw

On Tue, Jul 27, 2021 at 10:47:36AM -0400, Olek Wojnar wrote:
> On Tue, Jul 27, 2021, 04:09 Peymaneh Nejad <p.nejad@posteo.de> wrote:
> > Is it intended or wished for that additional runtimes other than Java are
> > packaged in seperate source packages, or would it be better to add another
> > binary package (that'd be golang-github-antlr-antlr4-dev) to the existing
> > source?
> >
> 
> In principle, if the same source is used for all of the binaries, I feel
> that we should maintain a single Debian source package. Unless there's some
> compelling reason to split them.
> 
> I can't think of a good reason to split source but I can definitely think
> of several good reasons to have a single source package! e.g. inter-binary
> compatibility, security updates, etc.

Agreed!  Thank you Peymaneh and Olek.

[toc] | [prev] | [next] | [standalone]

#12260

Hi Peymaneh,

Le 2021-07-27 10:09, Peymaneh Nejad a écrit :

> Is it intended or wished for that additional runtimes other than Java
> are packaged in seperate source packages

Yes it is, for several reasons:
- The Java Team doesn't have the time and skills to maintain properly a 
multi-language package like ANTLR. The Java part is sufficiently complex 
on its own, we'd rather not have to care about the other languages.
- Different language ecosystems often require distinct and slightly 
incompatible versions of ANTLR.
- Handling several languages in the same package makes upgrades and 
regression testing much more difficult.
- ANTLR is a core package of the Java ecosystems, including more 
languages increases the dependency tree of the Java packages and makes 
the bootstrapping harder.

So it's preferable to have a clear separation of responsability with 
different source packages, each language team having the freedom to 
maintain its version as needed without impacting the others.

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#12261

Hello Emmanuel,

Am 28. Juli 2021 08:41:46 MESZ schrieb Emmanuel Bourg <ebourg@apache.org>:
>> Is it intended or wished for that additional runtimes other than Java
>> are packaged in seperate source packages
>
>Yes it is, for several reasons:
>- The Java Team doesn't have the time and skills to maintain properly a 
>multi-language package like ANTLR. The Java part is sufficiently complex 
>on its own, we'd rather not have to care about the other languages.
>- Different language ecosystems often require distinct and slightly 
>incompatible versions of ANTLR.
>- Handling several languages in the same package makes upgrades and 
>regression testing much more difficult.
>- ANTLR is a core package of the Java ecosystems, including more 
>languages increases the dependency tree of the Java packages and makes 
>the bootstrapping harder.
>
>So it's preferable to have a clear separation of responsability with 
>different source packages, each language team having the freedom to 
>maintain its version as needed without impacting the others.

Thanks for the explanation, that makes sense. 
Then I'll go on with a seperate package. 

Peymaneh

[toc] | [prev] | [next] | [standalone]

#12262

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 28, 2021 at 08:41:46AM +0200, Emmanuel Bourg wrote:
> Hi Peymaneh,
> 
> Le 2021-07-27 10:09, Peymaneh Nejad a écrit :
> 
> > Is it intended or wished for that additional runtimes other than Java
> > are packaged in seperate source packages
> 
> Yes it is, for several reasons:
> - The Java Team doesn't have the time and skills to maintain properly a
> multi-language package like ANTLR. The Java part is sufficiently complex on
> its own, we'd rather not have to care about the other languages.
> - Different language ecosystems often require distinct and slightly
> incompatible versions of ANTLR.
> - Handling several languages in the same package makes upgrades and
> regression testing much more difficult.
> - ANTLR is a core package of the Java ecosystems, including more languages
> increases the dependency tree of the Java packages and makes the
> bootstrapping harder.
> 
> So it's preferable to have a clear separation of responsability with
> different source packages, each language team having the freedom to maintain
> its version as needed without impacting the others.

I don't disagree with Emmanuel's statements about the importance of
ANTLR and why it is helpful to maintain separation.  However, I don't
think introducing a separate source package each language ecosystem is
necessarily best for Debian.

It causes additional work for the Security team when in the event there
vulnerabilities.  It potentially confuses users (and Debian developers)
by creating a distinction that does not exist upstream.  It also means
that we will release with different versions of ANTLR for different
languages, which feels very "non-distro" to me.  (What happens if the
version of the ANTLR parser for language X is subtly incompatible with
language Y, and a user runs a system on Debian that requires both
bindings?)

tony

[toc] | [prev] | [next] | [standalone]

#12263

[Multipart message — attachments visible in raw view] — view raw

On Wed, Jul 28, 2021 at 08:41:46AM +0200, Emmanuel Bourg wrote:
>> Hi Peymaneh,
>>
>> Le 2021-07-27 10:09, Peymaneh Nejad a écrit :
>>
>> > Is it intended or wished for that additional runtimes other than Java
>> > are packaged in seperate source packages
>>
>> Yes it is, for several reasons:
>> - The Java Team doesn't have the time and skills to maintain properly a
>> multi-language package like ANTLR. The Java part is sufficiently complex on
>> its own, we'd rather not have to care about the other languages.
>> - Different language ecosystems often require distinct and slightly
>> incompatible versions of ANTLR.
>> - Handling several languages in the same package makes upgrades and
>> regression testing much more difficult.
>> - ANTLR is a core package of the Java ecosystems, including more languages
>> increases the dependency tree of the Java packages and makes the
>> bootstrapping harder.
>>
>> So it's preferable to have a clear separation of responsability with
>> different source packages, each language team having the freedom to maintain
>> its version as needed without impacting the others.

> I don't disagree with Emmanuel's statements about the importance of
> ANTLR and why it is helpful to maintain separation.  However, I don't
> think introducing a separate source package each language ecosystem is
> necessarily best for Debian.

> It causes additional work for the Security team when in the event there
> vulnerabilities.  It potentially confuses users (and Debian developers)
> by creating a distinction that does not exist upstream.  It also means
> that we will release with different versions of ANTLR for different
> languages, which feels very "non-distro" to me.  (What happens if the
> version of the ANTLR parser for language X is subtly incompatible with
> language Y, and a user runs a system on Debian that requires both
> bindings?)

Chiming in here, since it was originally me who asked Peymaneh to contact
this list, and I was sponsoring the same.
I was initially of the same opinion that it should be unified into a
single source package, but ebourg's points against doing that are pretty
strong too.

While I do not disagree w/ tony on this, but there already exist
antlr4-cpp-runtime[1] and python3-antlr4[2] packaged separately, and
indeed, they seem to have different versions than the Java antlr4 we
have -- 4.9 and 4.9.1 respectively as opposed to 4.7.2 in the java
antlr4 package

IMO, this is making it "non-distro" already.
There are also a bunch of other runtimes in other languages
which might as well need packaging at some point in time

Then, we have a few options:

1) Talk to the maintainers of cpp-runtime and python3-antlr to unify
sources with the original antlr4 source package
And this can be a very time consuming task there, since fundamentally
the versions differ quite a bit, and fixing it will take time

2) Do "$something-else" for all these packages to stay in sync - again,
probably bumping versions only when needed.
With this approach, I do not see a problem in introducing a Go runtime
source package there

Thoughts?

[1]: https://tracker.debian.org/pkg/antlr4-cpp-runtime
[2]: https://tracker.debian.org/pkg/python3-antlr4

Nilesh

[toc] | [prev] | [next] | [standalone]

#12264

On Thu, Jul 29, 2021 at 01:06:11AM +0530, Nilesh Patra wrote:
> On Wed, Jul 28, 2021 at 08:41:46AM +0200, Emmanuel Bourg wrote:
> >> Hi Peymaneh,
> >>
> >> Le 2021-07-27 10:09, Peymaneh Nejad a écrit :
> >>
> >> > Is it intended or wished for that additional runtimes other than Java
> >> > are packaged in seperate source packages
> >>
> >> Yes it is, for several reasons:
> >> - The Java Team doesn't have the time and skills to maintain properly a
> >> multi-language package like ANTLR. The Java part is sufficiently complex on
> >> its own, we'd rather not have to care about the other languages.
> >> - Different language ecosystems often require distinct and slightly
> >> incompatible versions of ANTLR.
> >> - Handling several languages in the same package makes upgrades and
> >> regression testing much more difficult.
> >> - ANTLR is a core package of the Java ecosystems, including more languages
> >> increases the dependency tree of the Java packages and makes the
> >> bootstrapping harder.
> >>
> >> So it's preferable to have a clear separation of responsability with
> >> different source packages, each language team having the freedom to maintain
> >> its version as needed without impacting the others.
> 
> > I don't disagree with Emmanuel's statements about the importance of
> > ANTLR and why it is helpful to maintain separation.  However, I don't
> > think introducing a separate source package each language ecosystem is
> > necessarily best for Debian.
> 
> > It causes additional work for the Security team when in the event there
> > vulnerabilities.  It potentially confuses users (and Debian developers)
> > by creating a distinction that does not exist upstream.  It also means
> > that we will release with different versions of ANTLR for different
> > languages, which feels very "non-distro" to me.  (What happens if the
> > version of the ANTLR parser for language X is subtly incompatible with
> > language Y, and a user runs a system on Debian that requires both
> > bindings?)
> 
> Chiming in here, since it was originally me who asked Peymaneh to contact
> this list, and I was sponsoring the same.
> I was initially of the same opinion that it should be unified into a
> single source package, but ebourg's points against doing that are pretty
> strong too.

<snip>

> 2) Do "$something-else" for all these packages to stay in sync - again,
> probably bumping versions only when needed.
> With this approach, I do not see a problem in introducing a Go runtime
> source package there

100% agreed.  I don't mean to belabor the point.  Thank you for the
discussion and for the links to the other language packages.

Cheers,
tony

[toc] | [prev] | [next] | [standalone]

#12265

Hello,

Maintainer of antlr4-cpp-runtime here.

On 2021-07-28 22:36, Nilesh Patra wrote:
> 2) Do "$something-else" for all these packages to stay in sync - again,
> probably bumping versions only when needed.
> With this approach, I do not see a problem in introducing a Go runtime
> source package there

I was not aware of out-of-sync problem, thanks for pointing it out.
Maybe an antlr4 packaging team could be set up to coordinate
synchronized version bumps?

Best,
Andrius

[toc] | [prev] | [next] | [standalone]

#12266

[Multipart message — attachments visible in raw view] — view raw

On Thu, Jul 29, 2021, 03:09 Andrius Merkys <merkys@debian.org> wrote:

>
> Maybe an antlr4 packaging team could be set up to coordinate
> synchronized version bumps?
>

That sounds like a good compromise. And this way the Security Team would
have a single contact if there's a security issue.

-Olek

[toc] | [prev] | [next] | [standalone]

#12267

[Multipart message — attachments visible in raw view] — view raw

Hi Andrius,

> Hello,

> Maintainer of antlr4-cpp-runtime here.
>
>On 2021-07-28 22:36, Nilesh Patra wrote:
>> 2) Do "$something-else" for all these packages to stay in sync - again,
>> probably bumping versions only when needed.
>> With this approach, I do not see a problem in introducing a Go runtime
>> source package there
>
> I was not aware of out-of-sync problem, thanks for pointing it out.
> Maybe an antlr4 packaging team could be set up to coordinate
> synchronized version bumps?

While, It seems bit of an overkill to have an entire team for what will stretch
upto a maximum of 8 packages (8 supported run times for antlr4 yet)

But it seems worthwhile for us to keep versions in sync and get sane,
compatible versions to our users sure. I think
it does make sense creating such a team.
Please consider to stem ahead and do the needful

Kind Regards,
Nilesh

[toc] | [prev] | [next] | [standalone]

#12372 — antlr 4.10 released [Was: Re: packaging Go runtime for ANTLR4]

Hello,

Some time ago there was a discussion about the need to coordinate
uploads of antlr and its runtime packages, as in Debian they are split
into several source packages across several teams:

On 2021-07-29 10:09, Andrius Merkys wrote:
> Maybe an antlr4 packaging team could be set up to coordinate
> synchronized version bumps?

antlr 4.10 has just been released. How should we proceed with packaging?
What are the constrains?

I maintain antlr4-cpp-runtime. I plan to upload updated package to
experimental (needs to clear NEW) and wait for antlr 4.10 to appear in
unstable.

Best,
Andrius

[toc] | [prev] | [next] | [standalone]

#12269

Le 2021-07-28 21:36, Nilesh Patra a écrit :

> Thoughts?

I think you are trying to find a solution for a problem that doesn't 
exist.
Source packages per language isn't an issue that needs to be fixed.
antlr4-cpp-runtime works fine, python3-antlr4 works fine, 
libantlr4-runtime-java
works fine, the packages are independent and are free to evolve as 
needed
without impacting the others. An unified package will only bring pain 
and tears,
and distract us from more important topics (like the OpenJDK 17 
transition,
the Kotlin packaging or the Gradle upgrade).

Emmanuel Bourg

[toc] | [prev] | [next] | [standalone]

#12271

Le 2021-07-28 17:08, tony mancill a écrit :

> I don't disagree with Emmanuel's statements about the importance of
> ANTLR and why it is helpful to maintain separation.  However, I don't
> think introducing a separate source package each language ecosystem is
> necessarily best for Debian.

It's not optimal for the number of source packages in the distribution,
but it's optimal wrt the human resources available to maintain the 
packages,
and that's much more important than a few saved megabytes on the APT
repository mirrors. With separate source packages, I'm confident that
an issue with the Go/Python/C++ compiler and build tools won't hinder
the work on the Java library. Bootstrapping ANTLR4 wasn't a trivial task
(there was circular self dependencies) and I don't think I would have
been able to do it if I had to care about the other languages.


> It causes additional work for the Security team when in the event there 
> vulnerabilities.

AFAIK there was no CVE reported for ANTLR so far, so separate packages
do not induce an increased security maintenance in this case.


> It potentially confuses users (and Debian developers) by creating a 
> distinction that does not exist upstream.

I'm thinking about documenting in debian/README.source why the languages
are isolated in separate packages, this isn't the first time this 
question
arises.


> It also means that we will release with different versions of ANTLR
> for different languages, which feels very "non-distro" to me.  (What 
> happens
> if the version of the ANTLR parser for language X is subtly 
> incompatible with
> language Y, and a user runs a system on Debian that requires both
> bindings?)

We already have several versions of ANTLR for Java packaged (2.7.7, 3.2, 
3.5.2
and 4.7.2). If a new version of ANTLR creates regressions, we just clone
the package to preserve the old version. That's the only sane solution,
because you really don't want to test, debug and fix grammars with an
incompatible version of ANTLR, that's the reponsability of the upstream
developers.

Emmanuel Bourg

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.maint.java

csiph-web