[Bug 251117] [NEW PORT] www/palemoon: Open-source web browser

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251117

--- Comment #62 from Olivier Certner <olivier.freebsd@free.fr> ---
Hi Kubilay,

Thanks for popping in.

To first answer your questions:

1. The latest patch for 29.4.2.1 is indeed upstream's latest version.

2. QA: Makefile linted long ago, I've re-run portlint and I'll make a few minor
fixes to the Makefile. As for builds, there have not been recent poudriere
builds on FreeBSD infrastructure that I know of. Is it possible to request
some?

About tier-1 architectures, aarch64 is not supported. The port builds on amd64
and i386, but for the latter I don't think it is possible to build on a real
i386 machine, an amd64 box with 32-bit libs is probably necessary (linking
should take more than 4GB per ld process).

Recently, I've only built on 12-STABLE myself. Very recent reports by users
above indicate some failure on CURRENT, which is likely to manifest itself on
13-STABLE as well (after the last LLVM/clang update this summer). I have very
little time currently, I plan to build on 13-STABLE myself soon, but if someone
wants to help, he's welcome.

3. GCC is a mandatory requirement, because this is only what upstream supports
and the only thing that currently works. Also, we'll lose official branding if
we don't use it.

At start, I tried to get Palemoon working with LLVM/clang++, but the produced
binaries simply crashed, and light investigations did not reveal anything
obvious. I don't precisely remember now, and I don't know the actual amount of
work it would take. Anyway, I simply don't have the time currently and it's a
priori unlikely that upstream will accept the eventual patches to build with
LLVM/clang (when I brought the subject on the table months ago, I was very
strongly told not to do it).

As for bundled libs, I explained several times above why we cannot get away
with ports dependencies (API changes notably). This is a hard requirement (I
don't want/can't maintain a fork).

There is also the licensing concern (long discussion above in this PR, in
particular with bapt@). We can set RESTRICTED to solve it for now.

In a discussion with upstream during summer, they stated they wanted most
FreeBSD changes integrated into their codebase and build system, or they'll
lose interest, and possibly remove all BSD-related compatibility code. So the
long term fate of this port is mostly dependent on this process, which I
probably won't start before end of this year. So, pushing a port before that
appears to me as premature.

-- 
You are receiving this mail because:
You are the assignee for the bug.