• packaging Go runtime for ANTLR4

    From Peymaneh Nejad@21:1/5 to All on Tue Jul 27 10:10:01 2021
    Copy: ebourg@apache.org

    This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --WWUuNIQ2gqdsqPD2CptW3IUQgtXBwhWfC
    Content-Type: text/plain; charset=utf-8; format=flowed
    Content-Language: en-US
    Content-Transfer-Encoding: quoted-printable


    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


    --WWUuNIQ2gqdsqPD2CptW3IUQgtXBwhWfC--

    -----BEGIN PGP SIGNATURE-----

    wsF5BAABCAAjFiEErtcybf1Xe9fqLiOSPUlyYpTaU1AFAmD/vygFAwAAAAAACgkQPUlyYpTaU1CJ oRAAgSiHJE/I/DY/HSusmhHBpnrsNenskrh3x7Iaj7dK56NgVK6qV8XLygqYG7dNS9RtFimVuhyw BKw69vkEAqNOL1e/ATqKcF3gMiiGkzhHvJXfYMBjG7mGPgwusv00FGkxjCFdl5bfIGLnxFVv0Rpu 6sNVeCEabUkNRP0dEnI1ic1dPUMYnRfX2yIyAMF4z+SfcxogVCm7YzPeFoh08v7l7/N1JK8dihpi GVjQDOgOBwUOK+Y4Xf+U8k2rpFbqveELIuvmBn9VNKpX4GyG9vvbE4tn3+AT9ic6SED7sRRstaip KRdq/PAmUTBgSRVtvrGdMTBpk6P1KSjpZgHg6V3galiBiiF8mbx5xSygJAdC1YbPAGYpKAGZU98W z2Roeai/JWF5die3Eb5N0UZ9C8ore5/D0hz+X1VdKOUwIXiw1zFMYD5sm07HcjTLUV8Liw0IktgO PBGx+tRmrgrQN4iBIeyyMT0cKWxVWdazTTkAjGonIvJE30xJYQzi9j744NjCcG9XPIjOTvc8Iacv RZt0Qnn07OB1rhe1l/uhe5005iDkhU4FU13JfMVICQoaEQnmx5xgkB/rgnxA/ojyw9KJi2oRSSAh rCY8bmBu+v1ACLhKp5S4xesy5Enlz+e7aF8jlX3lJKPhLtJ3JWNisN6oC5cigTOeGezi9CV4Vz50 lF8=
    =hkvq
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Olek Wojnar@21:1/5 to p.nejad@posteo.de on Tue Jul 27 17:10:02 2021
    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.

    <div dir="auto"><div class="gmail_quote" dir="auto"><div dir="ltr" class="gmail_attr">Hi Peymaneh,</div><div dir="ltr" class="gmail_attr"><br></div><div dir="ltr" class="gmail_attr">On Tue, Jul 27, 2021, 04:09 Peymaneh Nejad &lt;<a href="mailto:p.nejad@
    posteo.de">p.nejad@posteo.de</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
    Is it intended or wished for that additional runtimes other than Java are <br> packaged in seperate source packages, or would it be better to add another <br> binary package (that&#39;d be golang-github-antlr-antlr4-dev) to the existing source?<br></blockquote></div><div dir="auto"><br></div><div dir="auto">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&#39;s some compelling reason to split them. </div><div dir="auto"><br></div><div dir="auto">I can&#39;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.</div><div dir="auto"><br></div><div dir="auto">-Olek</div><div dir="auto"><br></div><div dir="auto">PS Your GitHub link was broken for me and I don&#39;t have time to look up the
    source to verify my assumption.</div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tony mancill@21:1/5 to Olek Wojnar on Tue Jul 27 18:10:01 2021
    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.

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAmEAL0cACgkQIdIFiZdL PpYbOg/+OhLRWLIEPrBn0a97YYDjVbvXxkpAsEDQpXqIjyL7DcmSAbuQI3Ax5UEe RFoc4m7ql2uA+YQsmS+ICl76/nzeec0ET0FCLYySg31M3r+YkHylZhgMHpO1hujl vyezvV+tWLkKbc+YYLccCZi22y35IwnhXfbYddYpFwjsh1u5secaXQg8XTN23Bir E3bYVlg53cNDbTTrPIbTjokUUyt3fwqEFzijtoe00cn+PVyIm8C9D2k5EbCfyAsG qHOf39nmR+tYtzXQsFqJX6YbOeFUSdtztECzwTqPZiWxDRWyXbqmgtAwsSmGUrE6 wUoISM9EaaVcbj5FqxglKb62SzpyqPNWUVvW5p1ssnpwRkBd+rqSpHc3sagDtxTk NOh6jjEbUpL9zUR8JsI0DAOpkjjPHG0a54gv8iq5l2R39vI1W5279K+LUoh/mwmv WP2T8gz+inYBZ+sqg/Evib2h5H6DWRjgiysK+UULVPUeLQ7NfcAAF+/OOhpPGD8T CMfGgsjyTs3x8j78jr+oOSn9WSkti7BgRXSlcbFhSmRPlcgkaZS//4TZTog7MVmz cuPe9MEyW7V1CvWajSddNK4uYI7BAtnmyxL++5f3Yl0UHvIxw5pMAhfpRuQ0Hg5r 5AK3CYwSBPcmGZQ+CinSXjc4/MGakbqi5yNJGu+LlT6oa7QcfPc=
    =X0Qd
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Wed Jul 28 10:10:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Peymaneh Nejad@21:1/5 to All on Wed Jul 28 11:20:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tony mancill@21:1/5 to Emmanuel Bourg on Wed Jul 28 17:10:01 2021
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAABCgAdFiEE5Qr9Va3SequXFjqLIdIFiZdLPpYFAmEBctMACgkQIdIFiZdL PpZmBhAAiI4f4KxmZ722TUsy0tPRHJ0ZkP32Re21lkQ+HmUv6m6gL7Y3tCOY1rYJ sC0C2r25AsHrM9yzzDOH+VgTNjR2wXHrSGgqpeCsvdDOI/XXCjVh4sZFiVOlOQXG uWj5wi/xP7JdKN/yhumOHtqO4ebs919w7IOGUe4tPGXadPPGIdnUZth6SvUxagD0 I/RlgKHVBB0JQchwPyGKDow0cb43lSS+UQ6ialSRh8AjSV4jUu+VeM1b4GVEmmhS tO+ONx1Lm4uqiHPqKZHF8y9WhBbOULgGm2tq12rjuJh4wiKzYid71zDvC2BuDV19 IR7rlS7xDzmbKoAmHeWCwI/d5b8+K/hNcgFc1T3VueSJQEGN4zN8FNSbHJHuPIyc G7bR/msiaVcsJDdDiV1kjY28TNy9BxHCDSzkGmdo2ZKChGNeq9wISz29wBVz2NJ5 PYb+/iIa2dwnRQsdyAAdXF94qcLrU2hZKzwvDboW1oQsxaXDIfq2uXSZaFzaV5Pb AlA5ez0IOrOBk7KGBiSpHZtAcNpcNlGIg3uTCwsXvvaYeLJTAY00atBnvdcz75t8 yM0Gzdk8T+QdAV3X9xEz3Uy0x4F9jlq4V8NuVZLU1mrH28laK4R8Qru1k4zB3pD1 ouCoQmL1466E9+5WY/neLhLdCTDAsNAOoFzDdyjX+pc93FdgGX8=
    =aOyn
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tony mancill@21:1/5 to Nilesh Patra on Wed Jul 28 21:50:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to Emmanuel Bourg on Wed Jul 28 21:40:01 2021
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmEBsacACgkQALrnSzQz afHUKxAAmwCQkLddO1eq9P8auhnh3w3NIq35xGBP8AoZaNoS6I5f/XwkSpDiH6XK ZyepSpq1RKWjW7uyTN7I1CC+1HgtROIaPZE15BIcY10n1ffoJpnyz75RrvHmIdJo rdVupwPGOmKEdc7/KudZndszYMkWVJyWZErz/ckVHRgqnTwpiEFel8jtmJJxiLEk q2pX4WwY676aInqy5zjOzfCAHu+4xGg0NR6SfPDnytlsBMEFlb+m9ohlK8osU9/X q71AJvtA2LSq481beppyxdkjO5ZdswjYbSCOFVofqx3EKD82TvgH8pRMYuqZkykX ckQe5Bm/3nTbTEzhAf6epge6yITYGiWQd5bUASlWkU551FmfJxAgwL5fFPDqOeeF RZv1mBePlebYrI0RRNGSNeyV48XnyAisQtGBtg+3PiCHmWR/nx7na/Ok+bKyvbNi 0VytaTsA4p1h9+IMpK4yhEZ+6CYLOPfw/wfkO+VYobvA8QAUossiKEghNatD5EJ+ to5za+i19h+QTmsDP/UOZKscrAXJZkdqllCZ8INKdJ5K9gDdk3pRycOZUqV6bFWb h49Ozqp6BJbLPghCxkEdsaBEqSaUYYQdHifj+4e8A7fR5P/bgaJaV1Ua6Ukv1QFC SZ3HAsINCSWvizzw6ZrU6tQcqv3gFT8aIaUy6VWOLhBplCwcvYQ=
    =F9ID
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Andrius Merkys@21:1/5 to Nilesh Patra on Thu Jul 29 09:10:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Olek Wojnar@21:1/5 to merkys@debian.org on Thu Jul 29 16:20:02 2021
    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

    <div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Jul 29, 2021, 03:09 Andrius Merkys &lt;<a href="mailto:merkys@debian.org">merkys@debian.org</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0
    0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
    Maybe an antlr4 packaging team could be set up to coordinate<br>
    synchronized version bumps?<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">That sounds like a good compromise. And this way the Security Team would have a single contact if there&#39;s a security issue.</div><div dir="auto"><br></
    <div dir="auto">-Olek</div></div>

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Nilesh Patra@21:1/5 to All on Thu Jul 29 21:50:01 2021
    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

    -----BEGIN PGP SIGNATURE-----

    iQIzBAEBCgAdFiEEPpmlJvXcwMu/HO6mALrnSzQzafEFAmEDBcQACgkQALrnSzQz afH5Ug/+N6CXtOI+6NcpXd0mIDPKyo+xtaqAXvrMvEoT6MeivLVmwAo2UbAG2s3g f1JNgt0xoO+XuEvqmVlZ3WMYaPJ0VPHDsgKtgtYAJPtqtZ6+lNVCxwMartNnBfjM +TWEYG3jKwuXryR+jMtK/Lr9XVOawxd1jb02GStaFQaxE8ij1QDNVZtHTXPlqPKl jwtOfEzHKKOkG4uY0QDs7YwnHZK5CawBQ5PHnBy055YtxJtO6fIe3X+9eiJIxnyv yJ6SLFfaM8/a6w4KLNOU+dVByTf64WPGzjMx0O2vl35HW+B+0AB0W0XL/5D1uWBW 0ilAnT1xZgnCyY6Bj4eFPSxhmuRPMMm8JyUXqTDSE6lxGjxNIxv71VBwTP7Pitlm DTJ2iKLotAuDyyKfYTHkyV0GwbU50NHtHJr8GVDFtoe/hc4rqGJ6AXJLhxozjZOE eYX9/yWdI6MlN1J9KHgN/i1/DQz8UfTeewb+71pS6kEViWUaf61ByJ6BTexXdKB1 gPdhSJVjFk+w4hZLtXDgd0APWqOTmFj3DX51MjMc8Xx9wOsinMbcPOInJDTNKSIV LYETIyeAo0/wQszR1YxTyfL/uTs6dBUGJXm8lV6fofbICsy1w0WvVm+TItyL//xx 2547xKmRqiP5oDzrloapKSQve7GABsVSO4Yz7N79d+fvv6Se74E=
    =Rnt9
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Fri Jul 30 02:40:02 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Emmanuel Bourg@21:1/5 to All on Fri Jul 30 05:50:01 2021
    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

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)