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
