Re: packaging Go runtime for ANTLR4
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.
> 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.