As much I dislike the Pale Moon management and would advise people against using this browser, at this point, removing the package entirely will likely upset even more users.
We should just remove --enable-official-branding or better make it optional for users to enable, like we do already for Firefox.

I think you are right. I'll prepare that change (along with enableOfficialBranding option).

(By the way, Firefox now comes with official branding enabled by default after someone from Mozilla said our patches are OK.)

The only concern that's left is that Pale Moon -> New Moon rename also might confuse users. Perhaps, this should be in release notes, there's not much else we can do about that.

Don't worry about it. If it's an attribute name change please add a compatibility alias but if you just mean the name the browser displays then there's no issue.

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

The best of all world is to de-brand the package. "Looking fine" does not suffice, and I am not a graduated lawyer yet, so a more conservative and less risky approach is in order.

When packaging it I overlooked the fact that is uses the bundled libraries but it should use those provided by Nix in priciples.

Substituting in-tree libs for system libs, beyond the potential mismatch and subtle and hard to reconcile conflicts with the glue code, materially changes the nature of the end result. It's like baking a cake and using margarine, powdered eggs, and powdered milk instead of real butter, real eggs, and real milk.

You get something kinda close but it isn't the same thing.. It is something.. OTHER..

System libs won't have any specific feature or functional changes we have made to the lib code to make them suitable for the glue code.

In that case you would need to debrand and NOT offer any option for official branding. It wouldn't build with official branding anyway in that configuration. Besides, as explained, what you would producing would cease to be Pale Moon at that point.

Be sure to inform your users that they should not seek any support from us if you make these unwise changes.

We cannot offer any kind of support to packagers or users for unbranded builds or alternate build configurations. Nor is there any guarantee that the codebase will be stable and in any kind of working condition in that configuration.

You have to understand that a classical mozilla style codebase is not like any other piece of software out there.. It cannot be treated exactly the same as everything else. It requires care and due diligence.

@AndersonTorres
I am one of those people who check configure options for sanity.. So I would know.. When I say it "looks fine" then you can count that as an authoritative response.

This "conservative approach" is VERY risky because of the reasons outlined above. We have seen that strange things happen when you mix random system libs into the glue code and produce a binary like this.. Basically, it is a code mismatch.

@rnhmjoj Please don't let @yegortimoshenko crusade against our project cloud your opinions of us or my self. By all means, I am not perfect but I do try to learn from my own mistakes. A few bad interactions elsewhere is not the sum of who I am.

Beyond the strictly technical issues all we want is to ensure that when a user installs and uses Pale Moon what they are getting IS indeed Pale Moon. As it stands, that is what you are producing and it is fantastic.

However, if you make these changes then well.. I have no idea what it is you are putting out at that point.. But it isn't going to be Pale Moon and your users will suffer because of this.. I ask you to please leave things as they are because they are perfect as-is.

But failing that, perhaps you should just remove the offering completely because yet another system lib configured unbranded build really helps no one unless you are gonna actually DO something with it beyond grab the code and build.

Also, sorry for all the edits and revisions. I wanted to make sure that I was clearly expressing what I wanted to say. Also, mobile github isn't that great for this so I rewrote from my workstation.

I understand your reasons well, I just disagree with the means. Regarding OpenBSD, if you say that was a mistake then that's fine with me. The free and open source software community is already small and fragile without people hating and attacking each other.

Anyway non-technical matter aside, It's just that this is generally against the design of Nix and other distributions of maintaining a curated set of packages where each package should use the dependencies provided by the package manager to reduce disk space and compile time, allow easy patching, not mixing licenses, tracking dependencies etc.

Firefox, Chromium, other browsers and the vast majority of packages are doing this but there are exceptions, so I guess this could be one but I don't have a lot of experience and knowledge of Nix to say a definitive yes or no. I can surely say that I don't want the package removed because that would the possible worst solution for everybody, particularly for users that may see their browser of choice removed for reasons they couldn't care less.

That is the issue though, their browser of choice is being removed and replaced with something else (albeit similar) if this goes forward. However, it is your decision but please do inform your users of the change and the repercussions of it. Please don't leave them confused.

The problem with using bundled libraries is that it makes tracking CVEs in those libraries impossible, and trademark policy specifically prohibits patching source code, so we can't patch it ourselves without debranding. Also, see Debian thread and FreeBSD thread.

It would be nice if Pale Moon distributed patches on top of modern versions of libraries that we could apply. 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:

That would cause it to not be built on Hydra, so it seems to be a better idea to debrand it from user's perspective.

For example, we currently have jemalloc patch to make it work on aarch64, sqlite in Pale Moon is one minor version (three months) behind, NSPR is two minor versions (6 months) behind, etc. Also even though I couldn't find unpatched CVEs, I think it's important to be able to patch code that we ship without asking for permission.

That said, @mattatobin raises a valid concern: since Pale Moon patches third-party libraries for compatibility with older Gecko, there might be a point in the future where our builds that use native libraries destabilize to the point where we would have to keep older versions of the libs, or patch ourselves, or drop Pale Moon from the tree.

In that case, someone can contribute palemoon-bin derivation that runs Pale Moon in FHS environment, that would make it possible to use official branding, without having to build it by yourself. But as of source-based derivation, defaulting to system libraries and New Moon branding seems to be the best option.

Any updates on this pull request, please?

Upstream confirms the configuration is acceptable as-is (the current update PR). I can still take a shot at an updated Pale Moon/New Moon split if you think it makes sense.

Thank you for your contributions.
This has been automatically marked as stale because it has had no activity for 180 days.
If this is still important to you, we ask that you leave a comment below. Your comment can be as simple as "still important to me". This lets people see that at least one person still cares about this. Someone will have to do this at most twice a year if there is no other activity.
Here are suggestions that might help resolve this more quickly:

1. Search for maintainers and people that previously touched the
   related code and @ mention them in a comment.
2. Ask on the NixOS Discourse. 3. Ask on the #nixos channel on
   irc.freenode.net.

Ping @yegortimoshenko

Closing it because, well, everything is OK now.