Path: csiph.com!newsfeed.xs4all.nl!newsfeed9.news.xs4all.nl!bofh.it!news.nic.it!robomod From: tony mancill Newsgroups: linux.debian.maint.java Subject: Re: packaging Go runtime for ANTLR4 Date: Wed, 28 Jul 2021 21:50:02 +0200 Message-ID: References: X-Mailbox-Line: From debian-java-request@lists.debian.org Wed Jul 28 19:42:29 2021 Old-Return-Path: X-Amavis-Spam-Status: No, score=-6.601 tagged_above=-10000 required=5.3 tests=[BAYES_00=-2, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, LDO_WHITELIST=-5, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham autolearn_force=no X-Policyd-Weight: using cached result; rate: -5.5 X-Gm-Message-State: AOAM530AMLFz5E3Gsy7dXLAPL4UU6WufFmBTYpN/Z28ZCmH8bNwCo023 sSR7zG07EN3XBVLflRPQErPunSS8qqI= X-Google-SMTP-Source: ABdhPJzDk5B4ecxqaWHSQpkNmiMsHAqD0VH+0cvrrachaDjDLXVCsgEM4EXEnefZYIeGZ/86aJ3Pfg== X-Received: by 2002:a65:4342:: with SMTP id k2mr498115pgq.138.1627501333114; Wed, 28 Jul 2021 12:42:13 -0700 (PDT) Sender: robomod@news.nic.it MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Mailing-List: archive/latest/22893 List-ID: List-URL: List-Archive: https://lists.debian.org/msgid-search/20210728194211.vhdtvc7xfoofctzp@lark Approved: robomod@news.nic.it Lines: 57 Organization: linux.* mail to news gateway X-Original-Cc: debian-java@lists.debian.org X-Original-Date: Wed, 28 Jul 2021 12:42:11 -0700 X-Original-Message-ID: <20210728194211.vhdtvc7xfoofctzp@lark> X-Original-References: <20210728150803.qfw5los2idiy24ld@lark> X-Original-Sender: tony mancill Xref: csiph.com linux.debian.maint.java: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. > 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