"Mikhail T." <m...@aldan.algebra.com> 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. _______________________________________________ freebsd-gecko@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-gecko To unsubscribe, send any mail to "freebsd-gecko-unsubscr...@freebsd.org"
