[feedback request] drop icecat

[q66]

Void has previously made it policy to avoid introducing random forks of major browsers. Despite that, we still have icecat in the repos, which seems to me to be pretty much just firefox-esr with altered branding and some custom extensions and changed settings. It is so close to just firefox-esr that the project no longer bothers to create their own release tarballs, so the icecat template in Void fully relies on custom tarballs created by @pullmoll, despite it usually also being policy that we package software from official release archives except in special cases.

So the question is, are those changes it brings worthwhile enough to warrant an entire new firefox build (this one even more annoyingly long than the ordinary one, since it has to generate the localization packages from scratch, which takes a significant chunk of the overall time)? And if those changes are in fact worthwhile, why can't they be done externally to our standard firefox build, in form of config tweaks and custom installable extensions?

This whole thing seems rather puzzling to me. One thing I heard raised as an advantage is that icecat has its own home directory path, so it doesn't conflict with mainline non-esr firefox, but that sounds more like an excuse than anything else to me.

@void-linux/pkg-committers

[Vaelatern]

Should it be proposed today, icecat would not make it in.

We also don't remove old packages without a stricter set of requirements than those we use for accepting packages. I personally have little issue with dropping it, but it might be weird for Void Linux to decide to randomly drop an existing package. Maybe mark it Restricted?

[the-maldridge]

Historically a seperate icecat made sense, but I no longer see the relevance of it. It sounds like the upstream is dead from a release standpoint, which makes it a hard argument to continue unless pullmoll is effectively now the upstream.

[pullmoll]

Icecat is a little more than just rebranding firefox-esr AFAICT: LibreJS, privacy enhancing configuration changes, removal of non-free or user rights restricting extensions (DRM, EME), removal of telemetry. See https://directory.fsf.org/wiki/Gnuzilla

The current situation is unsatisfying because since 78.x there are no official tarballs but just the makeicecat script suite which applies patches and creates the tarball. I'd love to avoid having to build the tarballs, yet I don't know when gnuzilla will resume publishing them again.

If you want to remove icecat, please do. Just don't count on me for explaining to anyone why it was removed.

[the-maldridge]

I think in many ways its just a curiosity. A link to the above comment would add a lot of context to why this template is being carried. Would it be practical to implement the template in such a way that it pulls the original tarball and runs mkicecat inside the do_patch phase?

[pullmoll]

Well, mkicecat itself downloads the firefox-esr tarball and verifies the sha256sum and signature. Then it takes a very long time to patch the sources - on our builders that would probably be hours. Doing this for every target in the do_patch() would slow it all down by a factor of 2-3 AFAICT.

[the-maldridge]

I see. Lets not do that then.

[ericonr]

The issue would be leaving icecat users with an older browser; we can't make it a meta package that depends on firefox-esr, because that'd block them from accessing their profile, so the only solution I can think of is leaving it stale and removing with removed-packages.

[q66]

well, I wouldn't just go and remove it; but it should definitely be investigated whether the custom extensions and settings can be added on top of firefox, and if they can, then there is no actual reason to keep it around

[uzr123x]

remove it and add SeaMonkey instead c: At least it's not merely 'rebranded' Firefox with a couple of addons, a new logo and some tweaked settings.

[tibequadorian]

just wanna say I'm glad that icecat is in the repository but I understand the argument

[travankor]

can do what #27419 suggests -- have a package that applies some better defaults to ff

[the-maldridge]

The decision for now seems clear to retain the package, thank you all for comments.

[pullmoll]

OT: Could we use a powerful build server or even master? I'm willing to sponsor an e.g. Hetzner AX161 with 1TB SSD (?) and 2x 10TB HDD for two years. Needs someone to do the setup and maintenance, though, as I'm not a good admin.

[the-maldridge]

Sure, lets discuss over in either the infrastructure repo or in IRC. Pick your preferred venue; I'd like to move the musl build box to the EU so we aren't taking packages transatlantic during the build cycle.

[q66]

I don't see how the decision is "clear". Also I want to keep this open so that it's not forgotten and we don't stay with the status quo forever

E.g. regarding LibreJS: looks like you can just install that into firefox as an ordinary addon from the usual place

[uber97]

I don't know if that's an idea Void maintainers would agree, but I'm thinking about shipping LibreWolf as a replacement for IceCat.

[the-maldridge]

We would drop without replacement @uber97. The intent and perhaps not clearly communicated goal here is to ship fewer forks of the major browsers.

[ghost]

Is there a reason why the alternative browsers aren't at least introduced as restricted so that users that want them can choose to xbps-src them themselves? The builds don't appear to be trivial even when taking existing templates and switching things around - that is to say it often fails.

[the-maldridge]

@tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

[ghost]

@tarkov2213 restricted is still governed by the quality bar for package inclusion, which among other things disallows packages that just rot in the repos.

But the stated reason for these packages (ungoogled-chromium, brave, librewolf etc) not being included is not their quality but compile time on the build server. If users requested them, they will be used. So how will they rot? Google chrome is there and it's not even source, which arguably is of much greater concern than any of these other packages (dependency breakage, security/inauditability, etc).

[ahesford]

"Restricted" means Void is, well, restricted from distributing the package contents. It is not a mechanism to provide templates we just don't care to build.

A key reason for not allowing other browsers is their excessive build time. That doesn't mean it's the only reason. Restricted packages tend to rot faster than regular packages because the tooling that ensures consistency of the repository is (necessarily) unaware of restricted packages, so we can't track potential breakage when we update other packages.

[ghost]

@ahesford fair enough, what about introducing another category for "templates we just don't care to build"? Because as things stand there really is no other choice for many of these packages other than to just hope they provide binaries and those binaries work. Even a sporadically maintained source build template would be better and after they are made updates would often consist of nothing more than changing a few numbers.

[ahesford]

That's called https://github.com/tarkov2213/void-packages

Void doesn't offer a user repository like Arch, but nothing stops you or anybody else from forking the repo and maintaining your own templates. The official repository bears the burden of maintenance. We strive (imperfectly) to keep everything well maintained, and providing official templates that we don't care enough even to build would take Void further from the goal.

[tibequadorian]

I might be wrong but void-packages is not really built for that. I found it very cumbersome as a user to handle templates from different forks, like manually copying over the folder containing the template and having no easy way of updating them...

[Gottox]

We had the browser discussion multiple times and I still think, that it is crucial for a browser to be well maintained. A task that no one but the original developers managed to do over a longer period of time. I'm all in for the removal.

[ericonr]

@pullmoll ok to close?

[q66]

in short to medium term we should perhaps look into providing an extra package to disable telemetry and so in default prefs, should be a sufficient alternative

[Raffadiely]

I use Icecat as a Unmozillaed Firefox, akin to the Ungoogled Chromium project. I'm sad to see it removed from Void, though I understand the reasons as to why.

Like q66, if I am to use Firefox, I would appreciate some kind of privacy patching package to be present in the repos (though I don't have the skill to create and maintain one myself).

In the meantime, and for anyone who finds this issue when they see Icecat in removed-packages, some good privacy tools for Firefox include Firefox Profilemaker or the arkenfox user.js.