Proposal to add firefox-esr to the official repos

Veldora · 2024-04-10 07:52:59

TL;DR add firefox-esr to the official repos, since there is a popularity grow in Arch in private and corporate sector. Companies that use Arch, might want to use more-stable software than most-recent, but still have the ability to run most recent hardware.

Okay, hear me out.

Currently, only firefox and firefox-developer-edition are available in the official repos. firefox-esr on the other hand only in the AUR.

You might wanna tell, that it's incompatible with the "Arch approach", as mentioned by tomk in 2012 in this post:
https://bbs.archlinux.org/viewtopic.php?id=134948

tomk wrote:

IMO ESR is incompatible with the Arch approach, so I'd be surprised if it ever turns up in the repos. The AUR, however, would be perfect for it.

However, Arch Linux does maintain some software, which do have a longterm-schedule.
Just to mention libreoffice-still and linux-lts.

(Also mentioned in this post in 2021: https://bbs.archlinux.org/viewtopic.php?id=272134)

If it's incompatible with the "Arch approach", why would these packages be in the official repos?

The other thing is, Arch is gaining more in popularity among privates and even companies.

And while privates use the default firefox packages, companies might tend to use firefox-esr to have only yearly feature-updates, instead of monthly ones, which sometimes tend to break specific "components" within firefox.

Additionally, Mozilla does prevent to configure search engines by policies.json in the default release of firefox.
(Mozilla Devs stated, they won't add it, due to security reasons and the possibility of search engine hijacking)

They only support it in the ESR edition, since they state it as "Firefox for Business".
https://www.mozilla.org/en-US/firefox/enterprise/

I and probably many other administrators in companies would be thrilled, to see firefox-esr in the official repos.

And IMHO, the maintaining shouldn't be much different than the official firefox package.

Allan · 2024-04-10 08:30:12

Veldora wrote:

TL;DR add firefox-esr to the official repos, since there is a popularity grow in Arch in private and corporate sector. Companies that use Arch, might want to use more-stable software than most-recent, but still have the ability to run most recent hardware.

The IT manager at those companies should be fired.

Veldora · 2024-04-10 08:33:08

Allan wrote:

The IT manager at those companies should be fired.

Any reasons for your statement?

I think everybody has the right to choose which OS and which "stability" they want. If they achieve it by tinkering, while it runs stable enough to use in production, give them a rather a raise, then firing them.

Allan · 2024-04-10 08:58:19

Sure. If a company selected Arch as their distribution, but "want to use more-stable software than most-recent", then they picked the wrong distribution. That shows incompetence, and the IT manager should be replaced.

Veldora · 2024-04-10 09:01:56

Allan wrote:

want to use more-stable software than most-recent

Maybe I used the wrong words.

I wanted to say, that they rather want to use software, which don't get a feature-release very often, rather just security-patches.
Which is the case in linux-lts, libreoffice-still and firefox-esr.

For example: linux-lts gets only security patches and some bugfixes are backported, but still it's considered as "more stable" than linux.
The same with firefox-esr, it gets security-patches through the year, and only yearly a feature-release.

This doesn't make the IT managers incompetent.

icar · 2024-04-10 09:40:24

Arch lacks any certification and corporate support to be considered for any enterprise environment. Use Ubuntu.

Veldora · 2024-04-10 09:41:18

icar wrote:

Use Ubuntu.

No

dcy3rka · 2024-04-10 11:23:26

Only out of wonder @Allan and @icar: what is the difference between the examples from Veldora libreoffice-still / linux-lts and firefox-esr? Why do we want one in the repo and the other not? For me as a user this sounds a little bit inconsistent and I found it sometimes very useful to switch to a security-maintained LTS/ESR/whatever version, if any bugs occurred in the latest build.

cmm11 · 2024-04-10 12:03:35

You's are overlooking the fact that a packager/maintainer would have to step up to maintain firefox-esr if it was to be added to the extra repo.
A browser isn't exactly the most simple thing to maintain. Also a kernel and a web browser are too very different things.

Veldora · 2024-04-10 12:25:08

@cmm11

cmm11 wrote:

packager/maintainer would have to step up to maintain firefox-esr

Well yes, this is an argument, which might cause the package to not make it's step into the repo.

cmm11 wrote:

A browser isn't exactly the most simple thing to maintain.

I don't have very much knowledge in maintaining a browser, but IMO, since it's the "LTS" release of an already existing extra/package, I don't think, there are many differences between maintaining the one or the other. The only difference which I currently see, is the tarball, which gets pulled. But I guess since @heftig is the maintainer of extra/firefox, he might have more knowledge in terms of maintaining a browser and maybe it's LTS variant.

cmm11 wrote:

Also a kernel and a web browser are too very different things.

I do know that and agree with it, but the fact that there are LTS versions and "normal stable" versions, is the actual topic, not how complicated those packages are to maintain.
I guess maintaining a kernel is much more of a challenge than a browser.

But coming back to the main topic:
It's not only the kernel, which has an LTS version, it's also libreoffice.

Arch has libreoffice-fresh in it's repos, which you could compare to "linux" or "firefox", it gets all the new fancy stuff, releases like every 4 months a new version and libreoffice-still, which could be more like "linux-lts" or "firefox-esr", which gets only security patches for a limited time (mostly about 2 years), until it's EOL and the next LTS release drops, which happens like only once a year.

So it's not about the packages itself, it's more the idea behind stable and LTS.
Why have some LTS packages in the repo and some not?

And even if firefox-esr has a lower marketshare than firefox,
I would rather say, that many people would actually prefer an LTS browser, instead of a browser, that gets all the latest features.

Allan · 2024-04-10 12:40:21

dcy3rka wrote:

Only out of wonder @Allan and @icar: what is the difference between the examples from Veldora libreoffice-still / linux-lts and firefox-esr?

I don't necessarily agree with either being in the repo, but....

When linux breaks, people can not boot their systems. Having the -lts as a backup is useful. Particularly as breakages can last a while before being fixed.
When libreoffice-fresh was first started, it was considered to be more a beta release. So it was added in addition to the usually packaged stable release. I don't know the current situation.

firefox-esr is not to fix failure to boot, nor is the firefox release considered beta by upstream. It is just an old package.

dcy3rka · 2024-04-10 12:57:27

@Allan: thanks for your clarification. I see your point.

About your statement "It is just an old package" I do not completely agree. firefox-esr is well maintained and has also slightly other features. Therefore it is just like a fork and not old.

In my opinion, there is nothing wrong with well-maintained software AND packages in the official repository. What is the disadvantage for Arch? It simply covers more use cases...

V1del · 2024-04-10 13:39:29

As always, the disadvantage for Arch is maintenance burden/resource usage. Find a maintainer that wants to do this, post a proposal on arch-general or whatever, but don't be salty when it gets shot down and not implemented. "You already do it for other packages" isn't an argument, obviously these other packages have maintainers that want to do this.

By the same general logistics you could wonder why the entirety of the AUR isn't in the standard repos and the answer is simply that, none of the currently active maintainers care to have it, your options are to find a maintainer that wants to do this, or become the maintainer that's doing this.

As for the argument that spawned this proposal. If you're using Arch seriously in a company environment that wants this, you probably want to have a pipeline in place for custom packages, in which you are free to add firefox-esr to your company private repository.

Last edited by V1del (2024-04-10 13:44:22)

Veldora · 2024-04-10 13:59:19

Thank you for your answer @V1del

V1del wrote:

your options are to find a maintainer that wants to do this

Well that's what I'm trying to do with this thread.
If I'm lucky enough, it might get the attention of other maintainers, which might pick-up the package for official maintenance.

Until now, only two other posts (those which I've linked in the first post), asked to maintain firefox-esr, which in the end weren't so active like this post here.
I've checked the arch-general archive and couldn't find anything, so before writing to a mailing-list, I tried my luck in the forums.

V1del wrote:

or become the maintainer that's doing this.

I don't think that's so easy to accomplish.
According to this Wiki-Post: https://wiki.archlinux.org/title/Package_Maintainers

I think I don't bring the basic-requirements with me.

V1del wrote:

you probably want to have a pipeline in place for custom packages

Well that's what we're currently doing with other AUR-pkgs and self-written PKGBUILD's

My concern was more to get firefox-esr officially maintained, so other users can use the official package, instead of an AUR package, which is not officially supported by Arch Linux and usage is at it's own risk. Also by having two options. If firefox happens to be broken with one release, users can try firefox-esr and see, if it's also broken: without having to compile it first.

V1del wrote:

"You already do it for other packages"

I agree with that.

My part here:

Veldora wrote:

But I guess since @heftig is the maintainer of extra/firefox, he might have more knowledge in terms of maintaining a browser and maybe it's LTS variant.

Was more as a statement, that @heftig might have the eye to see more differences between esr and "normal".
I was not trying to say, that @heftig should do it, since he already maintains firefox... if it came to you like that, I'm sorry.

Last edited by Veldora (2024-04-10 14:28:58)

dcy3rka · 2024-04-10 14:39:18

Okay, now we are getting from "The IT manager at those companies should be fired." and "Use Ubuntu" to "Find a maintainer that wants to do this". That's my understanding how Arch should work and I'm leaving this discussion now ;-)

V1del · 2024-04-10 15:16:54

Veldora wrote:

Well that's what I'm trying to do with this thread.
If I'm lucky enough, it might get the attention of other maintainers, which might pick-up the package for official maintenance.
Until now, only two other posts (those which I've linked in the first post), asked to maintain firefox-esr, which in the end weren't so active like this post here.
I've checked the arch-general archive and couldn't find anything, so before writing to a mailing-list, I tried my luck in the forums.

For reasons -- that I'm also not privy of -- most packagers do not really check/come here. So your best bet to find someone from the existing pool is post to the mailing lists/inquire the current maintainer via mail or so/post a feature request on the gitlab.

But as there have been previous attempts at this and they've not gained traction you could probably surmise that there's no interest here and I don't see the inherent benefit here that would have lead to a change of heart so I can tell you you should probably go in with low/little expectation.

I don't think that's so easy to accomplish.
According to this Wiki-Post: https://wiki.archlinux.org/title/Package_Maintainers
I think I don't bring the basic-requirements with me.

And yet most of the current maintainers ultimately started with a similar need and decided to actively do something about it.

Well that's what we're currently doing with other AUR-pkgs and self-written PKGBUILD's
My concern was more to get firefox-esr officially maintained, so other users can use the official package, instead of an AUR package, which is not officially supported by Arch Linux and usage is at it's own risk. Also by having two options. If firefox happens to be broken with one release, users can try firefox-esr and see, if it's also broken: without having to compile it first.

How often does this actually happen and would you not more generally crosscheck things with a different browser? In any case if you don't want to compile there's also firefox-esr-bin, all you need to do is check that the PKGBUILD downloads from the verified source with the verified keys.

Veldora wrote:

But I guess since @heftig is the maintainer of extra/firefox, he might have more knowledge in terms of maintaining a browser and maybe it's LTS variant.

The knowledge is likely the least problem and I'd assume large part of the PKGBUILD can be shared, but a browser compile will tie up even a beefy build server for quite a while (... which I'm assuming is also an unmentioned part of your proposal, you likely noticed that it's quite computationally costly to do this often)

But ultimately we're the wrong people to ask here and as mentioned, chances that the relevant packagers will see it here are quite low.

Veldora · 2024-04-12 06:46:44

V1del wrote:

For reasons -- that I'm also not privy of -- most packagers do not really check/come here. So your best bet to find someone from the existing pool is post to the mailing lists/inquire the current maintainer via mail or so/post a feature request on the gitlab.

Alright, I will see, what I'll do.

How often does this actually happen

Well, not very often, but we still had some issues, that were inside the Rapid Release (According to Mozilla), but not inside the ESR-Release

would you not more generally crosscheck things with a different browser?

Well if it's a website-rendering issue, sure, therefore we have chromium and epiphany (only for testing purposes and not for productional use).
But if it's an issue with the browser itself, which does not happen in one of the other two, I'd like to test it with a browser of the same make.

a browser compile will tie up even a beefy build server for quite a while (... which I'm assuming is also an unmentioned part of your proposal, you likely noticed that it's quite computationally costly to do this often)

True, this was unmentioned. firefox-esr takes alot of time, even when compiling with 16 cores at the same time. (which are not many for a "build-server", but is enough for small AUR-pkgs, e.g. gnome-extensions)

But ultimately we're the wrong people to ask here and as mentioned, chances that the relevant packagers will see it here are quite low.

Okay, thank you for this note.

I'd like to thank everyone that left some helpful comments on this issue/"proposal".
(And especially you @V1del, since you've never disappointed me so far. I'm always happy to see a comment from you)

WorMzy · 2024-04-12 10:55:59

Closing, on request.

Arch Linux

#1 2024-04-10 07:52:59

Proposal to add firefox-esr to the official repos

#2 2024-04-10 08:30:12

Re: Proposal to add firefox-esr to the official repos

#3 2024-04-10 08:33:08

Re: Proposal to add firefox-esr to the official repos

#4 2024-04-10 08:58:19

Re: Proposal to add firefox-esr to the official repos

#5 2024-04-10 09:01:56

Re: Proposal to add firefox-esr to the official repos

#6 2024-04-10 09:40:24

Re: Proposal to add firefox-esr to the official repos

#7 2024-04-10 09:41:18

Re: Proposal to add firefox-esr to the official repos

#8 2024-04-10 11:23:26

Re: Proposal to add firefox-esr to the official repos

#9 2024-04-10 12:03:35

Re: Proposal to add firefox-esr to the official repos

#10 2024-04-10 12:25:08

Re: Proposal to add firefox-esr to the official repos

#11 2024-04-10 12:40:21

Re: Proposal to add firefox-esr to the official repos

#12 2024-04-10 12:57:27

Re: Proposal to add firefox-esr to the official repos

#13 2024-04-10 13:39:29

Re: Proposal to add firefox-esr to the official repos

#14 2024-04-10 13:59:19

Re: Proposal to add firefox-esr to the official repos

#15 2024-04-10 14:39:18

Re: Proposal to add firefox-esr to the official repos

#16 2024-04-10 15:16:54

Re: Proposal to add firefox-esr to the official repos

#17 2024-04-12 06:46:44

Re: Proposal to add firefox-esr to the official repos

#18 2024-04-12 10:55:59

Re: Proposal to add firefox-esr to the official repos

Board footer