Inclusion of Pale Moon for Linux in distros

[pmnoob]

Perhaps this is Oh So Obvious, and I truly have no idea how much work / how many obstacles would be involved here (though I'd definitely like to know if anyone has a handle on it), but it would really be great to see Pale Moon in the official repositories for some popular distros. Personally, I'm thinking specifically of Debian, which of course would also pay off big because of all the derivatives. The Pale Moon branding could maybe be a problem there, though, because of the DFSG, like the Firefox/Iceweasel situation.

[Moonchild]

If inclusion in a distro means I have to give up my rights to my own branding and basically making it freely licensed along with the source code (which is a form of public domain) then it simply won't happen.

Pale Moon branded versions should remain of a controlled quality and intent. Having wild "derivatives" floating about with the same branding means nobody can provide proper support (since the derivatives can be configured completely differently), it's difficult to verify if the browser is still as-intended and/or built in a sane and responsible fashion, etc. The DFSG and similar "very open" licenses often work well for small tools with singular purposes, but they simply don't work well for very complex pieces of software like Pale Moon where a lot has to come together in exactly the right way to make it a desirable, efficient, safe program.

Re-branded versions a la IceWeasel built from the MPL-licensed source is, of course, never a problem, but the debian folks would be on their own in terms of providing release engineering, updates and support for that distribution.

For distributions that want to include Pale Moon in binary format, there are clear clauses in the redistribution license as to what is needed for that. Distribution in source form as part of a Linux distro is not a problem with the understanding that the end-user builds the browser on their own system strictly for their own personal use, and resulting binaries may not be redistributed. It's pretty straightforward licensing from my part, really.

[New Tobin Paradigm]

What needs to happen is NOT be apart of the distro repositories.. But for example provide packages for say fedora based operating systems that a user can tie into by adding our repo to yum. I am sure Debian and other package management systems has something similar. But it is the ONLY way to maintain proper control and quality of branded versions while allowing the convenience of package management that users would expect. Binary packages would only come from us as built by us.

What we still need of course is package maintainers to work with the our general linux maintainer to create the packages.

[trava90]

What needs to happen is NOT be apart of the distro repositories.. But for example provide packages for say fedora based operating systems that a user can tie into by adding our repo to yum. I am sure Debian and other package management systems has something similar. But it is the ONLY way to maintain proper control and quality of branded versions while allowing the convenience of package management that users would expect. Binary packages would only come from us as built by us.

This is something that I have looked into and would be willing to do, but at this point I don't want to be trying to keep up with releases on multiple fronts at the same time. Until/if I do provide repo's and/or ppa's, a dedicated package maintainer would be best.

[access2godzilla]

@trava90: this is not something particularly difficult, except for making the initial setup for the repo on the server. Making packages should be quite easy, and in fact I wrote a tool which should make the process easier.

[New Tobin Paradigm]

What needs to happen is NOT be apart of the distro repositories.. But for example provide packages for say fedora based operating systems that a user can tie into by adding our repo to yum. I am sure Debian and other package management systems has something similar. But it is the ONLY way to maintain proper control and quality of branded versions while allowing the convenience of package management that users would expect. Binary packages would only come from us as built by us.

This is something that I have looked into and would be willing to do, but at this point I don't want to be trying to keep up with releases on multiple fronts at the same time. Until/if I do provide repo's and/or ppa's, a dedicated package maintainer would be best.

Well.. Fedora/CentOS packages is something BinOC may do.. Though it won't be my self personally. I will have to bug Kudo about it again.. But this is something not especially important right now.. Maybe after the first of the year we can revisit it. Kudo (Binary Outcast's Second in Command) is currently doing secret work as a consultant and I am very busy with PM4XP and Adblock Latitude as well as theoretically the add-ons site.

[trava90]

@trava90: this is not something particularly difficult, except for making the initial setup for the repo on the server. Making packages should be quite easy, and in fact I wrote a tool which should make the process easier.

I actually have downloaded your tool, but haven't had a chance to try it yet. I was thinking of looking into it more after the first of the year when I will have a little more free time.

[New Tobin Paradigm]

@trava90: this is not something particularly difficult, except for making the initial setup for the repo on the server. Making packages should be quite easy, and in fact I wrote a tool which should make the process easier.

I would strongly discourage doing this. If at some point in the future we do offer distro-specific packages even though they will not be included in the distro's main-line repos we should endeavor to build Pale Moon as if they were. Using the target distros them selves and build on them. Package them as if they were and not pull a generico-catchall package for all fedora-based or all debian based. Of course the generic linux version will always need to be built for those systems that we do not currently create packages for but if this is going to be a possible thing then I think it should be done right.

[access2godzilla]

I would strongly discourage doing this. One of the key points of creating distro specific packages BEYOND being able to allow users to have the ability to do things via the package manager is to have more targeted builds for their specific OS. For Fedora and CentOS specifically one should build for CentOS 6 and 7 as well as Fedora Current and Fedora last version released. Otherwise, what advantage for the end user is there to even bothering imo.

The ability to update software with the package manager is the only reason why packages are made. As for the question as to why packages are compiled on the systems they're supposed to run on:
- For easier dependency tracking/resolution (which is no different for my tool: you must run it on the target distro).
- Unlike the Mozilla build process, not every other build process is clean and puts files in /usr and the likes directly.

[New Tobin Paradigm]

I would strongly discourage doing this. One of the key points of creating distro specific packages BEYOND being able to allow users to have the ability to do things via the package manager is to have more targeted builds for their specific OS. For Fedora and CentOS specifically one should build for CentOS 6 and 7 as well as Fedora Current and Fedora last version released. Otherwise, what advantage for the end user is there to even bothering imo.

The ability to update software with the package manager is the only reason why packages are made. As for the question as to why packages are compiled on the systems they're supposed to run on:
- For easier dependency tracking/resolution (which is no different for my tool: you must run it on the target distro).
- Unlike the Mozilla build process, not every other build process is clean and puts files in /usr and the likes directly.

So you don't think building a fedora/centos rpm should be done in a fedora/centos way.. Like using the Firefox spec file as a basis? and doing it specifically for fedora 32/64 AND doing it for centos 6 32/64 and centos 7 as well as providing the source rpm?

[access2godzilla]

First things first: are you planning to provide your own repo on your server, or are you planning to host the repo on the distro website server? If its the latter, you have to provide a source package, and thus cannot use my tool.

The tool sets up the post-install filesystem structure and invokes a packaging tool to build a package from the provided FS strcuture.

[SivaMachina]

I know this article is old now ...but apperantly Palemoon is in the AUR for Arch and its derivatives https://aur.archlinux.org/packages/?O=0&K=palemoon

[TanKe]

The problem for me is the linux installer script which does not work on every distro (mainly KDE based due to GTK incompatibility). Maybe an RPM and DEB packages may solve some initial problems about incopatibility.

[Moonchild]

The licensing for binary redistribution has changed recently to allow this kind of exception.
So, AUR and similar would be prefectly fine, although commercial Linux distros do still need to get an agreement with me.

See http://www.palemoon.org/redist.shtml, point 8, quoted below

An exception applies to point 5 of this license for inclusion of the officially branded binaries in freely available and fully Open Source operating systems, including but not limited to non-commercial variants of Linux, variants of BSD and ReactOS. This exception only applies to unaltered versions of the Pale Moon binaries or officially branded variants specifically built for the target operating system from unaltered sources (including brand-specific configurations like e.g. home page, default search engine). If any of the essential settings of the browser are altered beyond what is strictly needed for providing a working build on the target operating system, the exception in this point does not apply and the license defaults to point 10, instead.

(point 5 restricts inclusion of the browser in a larger works, point 10 outlines the needs for official endorsement for officially branded binaries)

[jumba]

Also, AUR is Arch User Repository, to share unofficial PKGBUILD files that are instructions to create own Arch linux packages. Pale Moon is not included in the Arch Linux package repositories.

[squarefractal]

Are there any updates on this? Although the provided installer does work, I'm sure many would prefer packages that can be updated with a package manager and that is thus tightly integrated into the system.

[Moonchild]

Are there any updates on this? Although the provided installer does work, I'm sure many would prefer packages that can be updated with a package manager and that is thus tightly integrated into the system.

Any updates on what, exactly? there's like 10 different things discussed in this topic

[squarefractal]

Whether there are any plans to provide packages for Pale Moon for various distros.

[Moonchild]

Whether there are any plans to provide packages for Pale Moon for various distros.

You're asking the wrong person.

I'm not going to do distro packaging. That is up to the distro maintainers to do. I don't have the required knowledge (or time) to begin with to know what the requirements and procedures are for distro-specific packages.

The redist license allows for redistribution in OS-specific repackaged form -- see the noted exception under point 3a -- so people are free to jump to it and make it happen.

[mozart78]

As it happens in Arch