| Summary: | www-client/firefox : introduce "ESR" USE flag | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alex <barracuda72> |
| Component: | Current packages | Assignee: | Mozilla Gentoo Team <mozilla> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jaak, kaikaikai, mattemod, sam |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Alex
2020-06-17 04:00:46 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. 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. 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. (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). 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 :-) 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). 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)
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. 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. (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. (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? (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. > > Such policies are not good for users who wish to migrate from regular > Firefox releases to ESR. Yeah we should have this documented, or preferably upstream detect a profile downgrade and start from "scratch" backing up the >ESR profile. > > 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. Out of curiosity, what were those compatibility issues? Related to mixing ~unstable with stable? > > 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. AFAIK there are no security issues with 78.15. I'm quite happy by not rushing to latest release, and let the worst bugs / update issues be weeded out first. Anyway yes, 91ESR is in the making. (In reply to Joonas Niilola from comment #13) > Out of curiosity, what were those compatibility issues? Related to mixing > ~unstable with stable? There was a website which didn't work well with Firefox 78. (In reply to Joonas Niilola from comment #13) > Out of curiosity, what were those compatibility issues? Related to mixing > ~unstable with stable? I only have a few ~unstable packages, none related to Firefox. The problem for me was that syncing and/or extensions stopped working properly and I need / heavily use a container extension which needs to be synced and fully working, so I had to upgrade to 91 non-ESR (which works properly). I have the same issue with FF 78.15 ESR on Debian (didn't have the time to upgrade to new stable release): it didn't sync properly, now it doesn't sync at all. And I don't just mean extensions: history and sometimes bookmarks too. Also, some websites stop working properly with older browser versions. Now that I recall, it actually happened with the last ESR major version upgrade too, so it's possible that it's an upstream FF Sync problem, where they drop compatibility for older ESR. If not, it'd be a pretty strange coincidence... twice. > > 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. > > AFAIK there are no security issues with 78.15. I'm quite happy by not > rushing to latest release, and let the worst bugs / update issues be weeded > out first. > > Anyway yes, 91ESR is in the making. I meant having to upgrade to 91 non-ESR while waiting for 91 ESR, not upgrading in the meantime to newer non-ESR versions to reduce downgrade compatibility problems (e.g. from 93 non-ESR to 91 ESR). I'm speaking from experience with the last ESR cycle, downgrading to 78.3 ESR from 80 non-ESR IIRC. So what I meant is that if you have to choose for example between 78.13 and 91.0 ESR, I think it'd be better to choose 91.0 ESR. Or at least 91.1 instead of 78.14 if you don't want the very first release because of bugs & co. If I could've stayed with 78.x ESR while waiting for 91.x ESR I would've done it, but as I said there were/are problems with it that were/are incompatible with my situation / needs. Well, 78esr is still supported and there is no engine change in later releases causing different rendering. I.e. a webpage working for 93.0 should work for 78esr the same. Could you please go into details regarding sync issue? I just tried our 78esr version and Mozilla sync works for me. But like Joonas said, 91er will land in Gentoo soon. Firefox and firefox-bin are now slotted, :esr or :rapid. You can utilize these slots to install the wanted release channel, or just follow our recommendation based on KEYWORDS (esr for stable, rapid for unstable). |
