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?
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.
Is it intended or wished for that additional runtimes other than Java
are packaged in seperate source packages
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.
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.
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.
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
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?)
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
Maybe an antlr4 packaging team could be set up to coordinate
synchronized version bumps?
<div dir="auto">-Olek</div></div>
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?
Thoughts?
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?)
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 62:18:09 |
| Calls: | 6,654 |
| Files: | 12,200 |
| Messages: | 5,331,626 |