Firefox Package Implementation in AnduinOS

[FromLinuxWithLove]

I'm curious: Is there a specific reason for providing your own Firefox package (firefox-anduinos) on AnduinOS? I believe you could save time and resources by simply adding the Mozilla package build out-of-the-box. Users should also get faster (security) updates with Mozillas official package. When I first installed AnduinOS, I was also slightly irritated that there wasn't an official Firefox package named "firefox", unlike on Ubuntu (even considering it's just a transitional package).

Right now, I am using the Mozilla package build on AnduinOS 2.0.3 without any problems. For both, Firefox and Thunderbird.

cat /etc/apt/sources.list.d/mozilla.sources 

Types: deb
URIs: https://packages.mozilla.org/apt
Suites: thunderbird-deb mozilla
Components: main
Signed-By: /etc/apt/keyrings/packages.mozilla.org.asc

[Anduin2017]

Thanks for the suggestion. The main question for me is actually not "why shouldn't AnduinOS add the Mozilla repository?", but rather: why should it add another repository at all?

AnduinOS's own package infrastructure, apkg, gives us fairly strong control over the software supply chain. As a general rule, I prefer to add as few third-party APT repositories as possible.

Ideally, an AnduinOS installation should only need to contact two package sources during apt update:

• Ubuntu
• AnduinOS

This becomes more important over time.

For example, imagine that some application currently available as a normal Ubuntu .deb package is later replaced by a Snap-only package, and AnduinOS still wants to provide a native Debian package for it. qBittorrent would be a good example of the kind of situation I mean.

If the solution every time is to add another upstream repository, then after several years an AnduinOS installation could easily end up with many third-party repositories.

That creates a lot of unnecessary operational risk. If even one repository changes its signing key, certificate setup, distribution layout, supported Ubuntu release, or simply becomes temporarily unavailable, it becomes something I need to investigate and maintain for every AnduinOS user.

So my preferred model is:

software that AnduinOS wants to officially distribute should, whenever practical, be distributed through the AnduinOS repository itself.

This also makes adding software outside the normal Ubuntu archive much easier. For example, I am quite interested in distributing tools such as xray and frp in the future, because I use them frequently myself. With the current model, I do not need to ask every AnduinOS installation to add another repository. I can simply publish another package through the existing AnduinOS repository.

Firefox follows the same philosophy.

firefox-anduinos is also not intended to merely be a differently named copy of an upstream Firefox package. It is the Firefox package maintained for AnduinOS.

Using Mozilla's repository directly would certainly work today, and users are completely free to do that. But I cannot guarantee that Mozilla's repository will always match every AnduinOS release and every requirement I may have in the future.

For example, if a future AnduinOS release is based on a new Ubuntu version and Mozilla temporarily does not provide the package I need, or if I need a build with different architecture/compiler options, dependencies, patches, defaults, or integration behavior, I do not want the availability of one of AnduinOS's preinstalled applications to depend on coordinating with another repository.

With firefox-anduinos, I can patch, rebuild, test, and publish the package myself whenever necessary.

For ordinary optional software, depending directly on upstream repositories is often perfectly reasonable. But for software that is preinstalled and officially maintained as part of AnduinOS, I value this level of package and supply-chain control quite highly.

So this is mostly an architectural decision rather than a Firefox-specific one.