Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 623954 - Why no stable ebuild for stable www-client/google-chrome?
Summary: Why no stable ebuild for stable www-client/google-chrome?
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Mike Gilbert
URL:
Whiteboard:
Keywords:
Depends on: 626388
Blocks:
  Show dependency tree
 
Reported: 2017-07-06 06:11 UTC by augustin
Modified: 2017-08-01 00:56 UTC (History)
4 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 augustin 2017-07-06 06:11:14 UTC
According to https://wiki.gentoo.org/wiki/Chrome :
www-client/google-chrome - A stable version of the web browser from Google.
www-client/google-chrome-beta - A beta version of the web browser of Google.
www-client/google-chrome-unstable - An unstable version of the nightmare web browser from Google.

www-client/google-chrome is supposed to be the stable ebuild for Google Chrome. Yes, there is no amd64 ebuild for it, only ~amd64. As a result, chrome was never upgraded on my system, and web sites start to complain that I am running an unsupported version of google chrome.

Why should the keyword change be required?:

$ emerge -p google-chrome

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild     U ~] www-client/google-chrome-59.0.3071.115 [47.0.2526.106_p1] L10N="en-GB%* fr%* zh-TW%* -am% -ar% -bg% -bn% -ca% -cs% -da% -de% -el% -es% -es-419% -et% -fa% -fi% -fil% -gu% -he% -hi% -hr% -hu% -id% -it% -ja% -kn% -ko% -lt% -lv% -ml% -mr% -ms% -nb% -nl% -pl% -pt-BR% -pt-PT% -ro% -ru% -sk% -sl% -sr% -sv% -sw% -ta% -te% -th% -tr% -uk% -vi% -zh-CN%" 

The following keyword changes are necessary to proceed:
 (see "package.accept_keywords" in the portage(5) man page for more details)
# required by google-chrome (argument)
=www-client/google-chrome-59.0.3071.115 ~amd64
Comment 1 augustin 2017-07-06 06:12:31 UTC
For comparison purposes, chromium  59.0.3071 is available in stable amd64:

* www-client/chromium
     Available versions:  59.0.3071.104^d ~60.0.3112.32^d ~60.0.3112.40^d [M]~61.0.3135.4^d [M]~61.0.3141.7^d
Comment 2 Brian Evans (RETIRED) gentoo-dev 2017-07-06 12:37:48 UTC
The reason is Google's policy.

Google pulls old releases the moment a new one is available. In addition, they do not allow us to mirror the downloads.

The Gentoo stable policy is to let an ebuild be available in unstable for 30 days and then have the arches test it.

This is just not possible with the mentioned upstream policy.
Comment 3 Richard Freeman gentoo-dev 2017-07-06 12:54:38 UTC
Don't want to turn this into a discussion but just wanted to point out that this happens in a few other situations as well.  I used to maintain an MMO client that had similar issues - when the server was updated the client had to be updated simultaneously, making a stable keyword pointless.  Users either ran the current version or none at all, making ~arch make the most sense.
Comment 4 Mike Gilbert gentoo-dev 2017-07-06 21:50:45 UTC
(In reply to Brian Evans from comment #2)
> The Gentoo stable policy is to let an ebuild be available in unstable for 30
> days and then have the arches test it.

A common exception to this rule is security updates, which are usually stabilized in a much shorter timespan.

Given that nearly every google-chrome release fixes at least one security bug, this presents a nice loophole for us to exploit in the policy. ;-)

Regarding the original question in this bug, I actually have no problem with giving google-chrome stable keywords. The long-term availability of the distfiles seems mostly unrelated to the stability of the software. If stable users get a fetch failure, that seems no worse than if they got the failure after adding it to package.accept_keywords. I generally resolve fetch failures within 24 hours anyway.

Also, the stable keywords were removed in the first place due to a protest from an arch team lead who no longer works on Gentoo. I'm copying the amd64 team in case they have an opinion today.
Comment 5 Richard Freeman gentoo-dev 2017-07-06 22:27:02 UTC
(In reply to Mike Gilbert from comment #4)
> 
> Also, the stable keywords were removed in the first place due to a protest
> from an arch team lead who no longer works on Gentoo. I'm copying the amd64
> team in case they have an opinion today.

It seems like this is the sort of thing we ought to have a consistent policy around.  If it doesn't make sense to apply the normal stable policies to a package, does it make more sense to just treat stable as if it were testing, or does it make more sense to just not stabilize the package at all?
Comment 6 Mike Gilbert gentoo-dev 2017-07-07 02:58:01 UTC
(In reply to Richard Freeman from comment #5)

In my experience, google-chrome is pretty solid; a given major version goes through several weeks of QA/testing before release. Our own Gentoo stabilization process really does not add much value here.
Comment 7 augustin 2017-07-07 06:05:11 UTC
Thanks. All your comments help us understand the dilemma.

It's up to you to decide what to do from a policy/developer perspective.

From a user perspective, it makes more sense to release in stable arch. 
The "Principle of least astonishment" would also dictate releasing in stable arch:
https://en.wikipedia.org/wiki/Principle_of_least_astonishment 


Whatever you decide, make note of the incongruity of what's described in the wiki (linked and quoted in opening comment). It was the dichotomy between what the wiki said (stable) and the reality of the ebuild (unstable arch) that prompted me to open this ticket.
Comment 8 Mike Gilbert gentoo-dev 2017-07-31 15:05:51 UTC
www-client/google-chrome-60.0.3112.78 is now stable on amd64. Thanks for the request and the feedback.
Comment 9 augustin 2017-08-01 00:56:42 UTC
Thank you for your time and help. :)