Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 728524 - www-client/firefox : introduce "ESR" USE flag
Summary: www-client/firefox : introduce "ESR" USE flag
Status: UNCONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mozilla Gentoo Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-17 04:00 UTC by Alex
Modified: 2021-10-21 23:56 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Alex 2020-06-17 04:00:46 UTC
I've got really tired of building firefox each time new version comes out.
Masking out each and every version isn't much of an option either, and ~ masks aren't really for that.
So I propose introduction of "esr" use flag for Firefox (and maybe some other packages).
The idea is that user can specify this flag and then get only ESR releases of package and their updates. Any regular versions will be skipped.
Just an idea for enhancement thou, nothing very serious.
Comment 1 Joonas Niilola gentoo-dev 2020-06-17 08:06:33 UTC
Or package it as firefox-esr? I do wonder if it is possible to use a USE flag to control version like this.

However I'd like to point out you can use > in package.mask, so >www-client/firefox-69 mask would've worked for a long time already. Obviously needs to be updated once new ESR hits the tree, but still less work than having to mask every version separately.
Comment 2 Thomas Deutschmann gentoo-dev Security 2020-06-17 11:24:00 UTC
There will never be a USE flag for this because a USE flag is the wrong way to do it.

I already thought about adding a slot.

For some time now I have the idea to allow having all firefoxes installed on the same system, slotted. But this isn't an easy task and we need to take care that new users don't accidentally break their profile.
Comment 3 Thomas Deutschmann gentoo-dev Security 2020-06-17 11:25:42 UTC
In the mean time you still can apply masks. I.e. if you want ESR, just mask >=www-client/firefox-70. This will at least work until next ~September... it's the same like enforcing a specific LTS kernel.
Comment 4 Sam James archtester gentoo-dev Security 2020-06-17 13:34:50 UTC
(In reply to Thomas Deutschmann from comment #3)
> In the mean time you still can apply masks. I.e. if you want ESR, just mask
> >=www-client/firefox-70. This will at least work until next ~September...
> it's the same like enforcing a specific LTS kernel.

Even better. Only ESR versions get stabilised. So, if they are running an unstable system, some line like:
"www-client/firefox -~amd64"
would work well, to only get stable versions of Firefox.

However, as we both know, Firefox ESR ends up bumped at the same time as Firefox (almost?) always for security reasons, so unless using ccache and such, the builds will take just as long as the new major version (ESR making not much difference).
Comment 5 tt_1 2020-06-17 16:07:19 UTC
on build time: firefox usually adds a few percent with each release, and firefox-esr bumps are a bit less frequent. 

also the stable policy for firefox is somewhat to never ever mark stable a non esr version, that should fix the problem of only pulling in esr. 

going full ~amd64 but keeping a few handselected packages on stable, without fuzzy package.mask entries, is done via -~amd64, as the comment right before mine mentioned it. a good canidate for that would be glibc, as it cannot be downgraded. 

if there's anything to speed up things for firefox-78, please bump someone nss to new nss-2.53, so that I can do extensive testing with firefox-78.0 beta before the merge window closes in a week. thanks :-)
Comment 6 Aidan Harris 2021-02-03 20:50:34 UTC
I'd like to propose that we have separate packages firefox-esr and firefox-esr-bin. www-client/firefox-esr should install into /usr/lib64/firefox-esr and www-client/firefox-esr-bin should install into /opt/firefox-esr. This would allow for both the stable and esr version to be installed simultaneously (this isn't currently possible as far as I know without using firefox-bin, if you want to compile both firefox and firefox-esr you can't).
Comment 7 Matteo Modesti 2021-10-05 12:15:13 UTC
Shouldn't this bug get closed or at least have the title changed to something generic like:
    www-client/firefox : separate ESR from normal release
...or more specific like:
    www-client/firefox : separate ESR to www-client/firefox-esr
    www-client/firefox : separate ESR in different slot
?

(I only use Firefox ESR, so I'm interested)
Comment 8 Joonas Niilola gentoo-dev 2021-10-05 12:32:48 UTC
You can now have esr controlled via your world file, 

# grep -i firefox /var/lib/portage/world
www-client/firefox-bin:0/esr78

Should work with -bin and non-bin. You'll need to add the slot by yourself by editing the file manually. 

91 will be updated to :0/esr91 naturally.
Comment 9 dE 2021-10-11 14:25:44 UTC
In the mean time, as per the release calendar -- 

https://wiki.mozilla.org/Release_Management/Calendar

Firefox 91 is also ESR, but I only see 78 in the portage tree.
Comment 10 Joonas Niilola gentoo-dev 2021-10-11 14:44:57 UTC
(In reply to dE from comment #9)
> In the mean time, as per the release calendar -- 
> 
> https://wiki.mozilla.org/Release_Management/Calendar
> 
> Firefox 91 is also ESR, but I only see 78 in the portage tree.

I don't think there are currently plans on going 91ESR before 78ESR is declared dead by upstream.
Comment 11 Jaak Ristioja 2021-10-21 17:33:02 UTC
(In reply to Joonas Niilola from comment #10)
> I don't think there are currently plans on going 91ESR before 78ESR is
> declared dead by upstream.

Such policies are not good for users who wish to migrate from regular Firefox releases to ESR. Here's my personal experience:

Due to compatibility reasons I had to upgrade Firefox 78 ESR to Firefox 86 and kept up with the regular releases up to version 91, hoping to stay with 91 ESR once that is released, so I masked versions 92 and later.

Later, when versions 92 and later were released, and the 91.#.# versions were removed from the tree, I was left between the following bad choices:
  (1) downgrading to 78 ESR which would again break things for me,
  (2) upgrading to later regular releases which would again mean no ESR, and
  (3) staying with an outdated and vulnerable Firefox 91.0.2 until Gentoo catches up.

What would your recommendation have been? Any other options?
Comment 12 Matteo Modesti 2021-10-21 23:56:56 UTC
(In reply to Joonas Niilola from comment #10)
> I don't think there are currently plans on going 91ESR before 78ESR is
> declared dead by upstream.
Now it's dead: last release is 78.15, released on 2021-10-05 together with 91.2 ESR.


(In reply to Jaak Ristioja from comment #11)
> Such policies are not good for users who wish to migrate from regular
> Firefox releases to ESR. Here's my personal experience:
> 
> Due to compatibility reasons I had to upgrade Firefox 78 ESR to Firefox 86
> and kept up with the regular releases up to version 91, hoping to stay with
> 91 ESR once that is released, so I masked versions 92 and later.
> 
> Later, when versions 92 and later were released, and the 91.#.# versions
> were removed from the tree, I was left between the following bad choices:
>   (1) downgrading to 78 ESR which would again break things for me,
>   (2) upgrading to later regular releases which would again mean no ESR, and
>   (3) staying with an outdated and vulnerable Firefox 91.0.2 until Gentoo
> catches up.
> 
> What would your recommendation have been? Any other options?
I find myself in the same situation: had to migrate to non-ESR 'cause 78 ESR stopped syncing properly at a certain point, now I'm stuck on 91 non-ESR until its ESR counterpart is released on Gentoo.


This is absolutely bad for security and honestly makes no sense: if there isn't enough manpower / resources to maintain both the old and new ESR versions, I think it'd make much more sense to choose the _NEW_ version instead of the old one.