From owner-freebsd-gecko@freebsd.org Sun Mar 29 20:17:53 2020 Return-Path: Delivered-To: freebsd-gecko@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 737D5261755 for ; Sun, 29 Mar 2020 20:17:53 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 48r6N02xVnz4Spb for ; Sun, 29 Mar 2020 20:17:52 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id DF2F426174C; Sun, 29 Mar 2020 20:17:44 +0000 (UTC) Delivered-To: gecko@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B513E26174B for ; Sun, 29 Mar 2020 20:17:44 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 48r6Mp6zXrz4Sm3; Sun, 29 Mar 2020 20:17:42 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1354) id 4CC38CC7E; Sun, 29 Mar 2020 20:17:35 +0000 (UTC) From: Jan Beich To: "Mikhail T." Cc: gecko@freebsd.org Subject: Re: Shared libxul.so (was Re: Restoring seamonkey) References: <857ef528-1dfd-12b6-6579-b03a137ff199@aldan.algebra.com> <9a797087-e769-3c50-3032-c71b41fab823@aldan.algebra.com> <4ku8-x9zl-wny@FreeBSD.org> Date: Sun, 29 Mar 2020 22:17:23 +0200 In-Reply-To: (Mikhail T.'s message of "Sun, 29 Mar 2020 11:33:11 -0400") Message-ID: MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: freebsd-gecko@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gecko Rendering Engine issues List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 29 Mar 2020 20:17:54 -0000 "Mikhail T." writes: > [Forking the Seamonkey thread, because the topic is different] > > On 28.03.20 20:47, Jan Beich wrote: >> libxul.so is no longer the same between various Gecko-based projects. > > It doesn't have to be /the same/ -- just needs to still be compatible > enough for a motivated developer to patch the rest. An argument added > here and there, a method deprecated -- such problems may be solvable > within a port. > > Maybe, libxul -- the best version (from firefox tree, I guess?) can be > moved into a port of its own, for firefox and others to use... Maybe, > a few such ports -- for different major versions, if necessary, the > way we have ruby22 and 24, for example. At best libxul.so from www/firefox-esr and mail/thunderbird can be shared. www/firefox, www/cliqz, www/seamonkey, www/palemoon are based on different Gecko versions. Major versions are released every month, bringing a massive code churn. API changes are probably similar to major LLVM releases except one can't rely on upstream fixing compatibility i.e., low bus factor. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1038639 > And, yes, I'd be willing to do it -- if I can be reasonably assured, > the work will not be rejected off hand on the grounds of "exhausting > maintenance" or some such. > > I've done it before, as a matter of fact -- it was my work, that once > changed firefox and thunderbird to use the common nspr and nss > (r1r141034, r41037), for example. Maintenance is a continuous effort. As you've given up on upstreaming some of your nspr/nss patches complicate updates. I'm guilty of this as well which is why I mainly keep statu quo nowadays. > Back then there was an agreement among port-maintainers, that sharing > components is a good thing -- do we still share this sentiment? It's a trade off. Unbundling has a benefit when it doesn't complicate maintenance much. Sometimes building a bundled dependency is harder than forcing a system version.