When using www-client/google-chrome, you can simply: emerge www-client/google-chrome:stable When using www-client/chromium, the "stable", "beta" and "unstable" slots aren't there. This makes it difficult to stick with a specific release channel. When a new version is released, you fist have to find out whether its a stable, beta or unstable version in order mask it or not. Then you have to find out what version of dev-lang/v8 goes with it and make sure to mask the correct version. Ad infinitum for every version for the lest of your chromium-using life. It would be much simpler if the same slots as for google-chrome were used. Probably with dev-lang/v8 too, so that each chromium slot can depend on the same v8 slot. Reproducible: Always
These slots aren't needed on chromium since the upstream release channels are separated by gentoo stable, unstable, and hard mask. The slots are needed on google-chrome because even upstream stable cannot be gentoo-stable, so there would otherwise be no way to only allow upstream stable.
I don't see the connection. Anyway, when I was using Firefox, I didn't have that problem. FF betas either don't make it into portage, or they are masked. Chromium betas are not masked. But they also aren't marked as betas. Chrome solved that with the slots. I do think we really need that for Chromium too, because, simply put: Gentoo testing != upstream betas.
If you want upstream stable chromium, just allow gentoo stable on it only. If you are on otherwise unstable, you can do "www-client/chromium -* amd64" in package.accept_keywords, for example.
Wouldn't that also block stable versions that are keyworded ~amd64? Which is kind of my point.
I think the request makes sense. I also have the same problem where "beta" releases are making it into ~testing and I install them without actually noticing it. Maybe slots are a bit overkill for this situation but keeping beta releases (maybe 23.X atm) masked would be preferred.
The google-chrome stable/beta/unstable slots line up with chromium keywords amd64/~amd64/~amd64[M] don't they?
(In reply to comment #6) > The google-chrome stable/beta/unstable slots line up with chromium keywords > amd64/~amd64/~amd64[M] don't they? Why should they? A new upstream version doesn't go into arch first. It goes into ~arch. Look at other packages. The current stable KDE version is 4.9. But it's not in Gentoo stable.
Yes but we aren't talkign about kde-- chromium is a special case, look at the commit times on the latest chromium-21.x: added to portage Fri Aug 31 20:01:47 2012 UTC amd64 stable Sat Sep 1 14:36:55 2012 UTC x86 stable Sun Sep 2 06:30:58 2012 UTC The versions consistently line up like I mentioned, but I don't know if this is stated somewhere as the official policy on gentoo's chromium versioning. I realize it does not provide the exact some functionality as google-chrome's slots but it's pretty darn close.
With google-chrome, we decided not to stabilize any releases because upstream removes distfiles and does not allow mirroring. This is what prompted the slot kludge. http://floppym.blogspot.com/2011/09/google-chrome-plan-b.html For chromium, gentoo keywords usually match upstream release channels: Dev channel = hard masked Beta channel = ~arch Stable channel = arch Stable channel releases are almost always security fixes, so they get fast-tracked STABLEREQ bugs. There are occasionally non-security stable releases, and we don't usually stabilize those right away. I have no problem changing this procedure if phajdan and the arch teams agree.
The problem with www-client/chromium slots is that often the same version is promoted from one channel to another. We would have to do a slotmove on the Gentoo side. Moreover, sometimes the same version is the latest one in two slots - we don't have good solution to handle that in Gentoo AFAIK. I think the _original_ problem here is easily solved by understanding the arch = stable, ~arch = beta, hard masked = dev channel scheme we consistently use. In other words, by default on a stable Gentoo system you're on stable, and on ~arch you're on beta (this is consistent with the rest of Gentoo). The same applies to dev-lang/v8 and any other Chromium components. If someone wants to stabilize non-security stable channel updates, I'm fine with that. Just not sure if the arch teams can deal with the increased load, and whether it's worth it (there's often just few days between those releases). Nikos, does the above address your original report?
Thanks for clearing that up. So if I understand correctly, it's how Ben described it; Chromium isn't like other packages (like Firefox) where the latest upstream stable (currently Firefox 15) can linger around in ~arch for months (arch only has Firefox 10), but goes into arch much quicker. So I suppose I can close this one :-)
