Pale Moon forum

Hello

I've registered here to get some feedback on the packaging job in the nixpkgs repository that I've sorta taken over after it had been abandoned for some time.

Previously, there have been concerns within our community about our use of the official branding flag and whether or not our build configuration and environment is correct enough to warrant its use. A consensus had not been reached, and the PR is still open (albeit unmergeable now).

yegortimoshenko wrote:

2018-03-13, 17:33

I would suggest dropping Pale Moon, because it's currently built with non-standard options and native libraries and upstream is aggressive towards this.

mattatobin wrote:

2018-03-14, 07:14

I dunno why you are debranding your package. Your build options look fine to me.

yegortimoshenko wrote:

2018-03-16, 22:47

Even if we were to leave Pale Moon as is, it probably should be under licenses.unfree, because modifications under that branding are not allowed, similar to Thunderbird:

Code: Select all

if enableOfficialBranding then licenses.proprietary else licenses.mpl11;

I like using Pale Moon and would like to keep using it on my preferred distro with the official branding, but I also understand your wish to only have it called "Pale Moon" if you can be sure that it actually behaves like "Pale Moon".
Thus, if possible, I'd appreciate it if someone could take another look at the packaging so far and let me know about any problems they might see with it and whether or not we may continue building it with the official branding.

If I can't implement changes required to permit the branding option, or it takes too long for me to do so, I will make sure to debrand our build for the time being.

The current package definition can be found here (working on updating it to 28.7.1).
I can provide a full build log and the output of about:buildconfig later today to make sure everything really is in the green with it.

Thank you, have a nice day.

The build configuration looks perfectly fine for official branding.

Not sure what yegortimoshenko's issue is -- building with the known in-tree (and specifically patched and tested) libraries is required for just about all supported OSes. Trying to enforce the use of system libs by policy won't work for our code base and distro maintainers should understand that a project of this size simply doesn't have one-size-fits-all policy compatibility. So yes, we are aggressive about that requirement because it is a requirement for stable (or even working) builds.

The branding is indeed not free-for-all. If that means you need to publish it as nonfree/proprietary (even if the software itself is released under a set of FOSS licenses) then so be it.