With the latest update of google-chrome ( 32.0.1700.77_p1 ), the profile directory in the ~/.config directory was renamed. The new version uses the directory "google-chrome" instead of "google-chrome-beta". The new version does not find the existing profile and shows a new, empty profile instead. Reproducible: Always Steps to Reproduce: 1. emerge the latest google-chrome version in testing (currently 32.0.1700.77_p1 ) 2. restart google-chrome Actual Results: Google chrome does not load my profile data. It creates a new profile which is empty. All bookmarks, passwords, history etc. "gone". Expected Results: Google chrome should always use the existing profile after an update. I figured out how to get my profile back: cd ~/.config ln -s google-chrome-beta google-chrome Restart chrome and you should have your profile back. Update history for google-chrome: qlop -Hl google-chrome Sat Oct 19 01:57:42 2013 >>> www-client/google-chrome-31.0.1650.16_beta1 Wed Oct 23 18:56:57 2013 >>> www-client/google-chrome-31.0.1650.26_beta1 Sat Oct 26 01:16:13 2013 >>> www-client/google-chrome-31.0.1650.34_beta1 Fri Nov 1 00:40:41 2013 >>> www-client/google-chrome-31.0.1650.39_beta1 Sat Nov 9 06:54:41 2013 >>> www-client/google-chrome-31.0.1650.48_beta1 Thu Nov 14 06:05:54 2013 >>> www-client/google-chrome-32.0.1700.14_beta1 Mon Nov 25 06:18:41 2013 >>> www-client/google-chrome-32.0.1700.19_beta1 Fri Dec 6 01:19:50 2013 >>> www-client/google-chrome-32.0.1700.41_beta1 Thu Dec 12 23:04:53 2013 >>> www-client/google-chrome-32.0.1700.55_beta1 Tue Dec 17 16:13:43 2013 >>> www-client/google-chrome-32.0.1700.55_beta1 Tue Dec 17 19:46:40 2013 >>> www-client/google-chrome-32.0.1700.55_beta1 Fri Dec 20 01:05:31 2013 >>> www-client/google-chrome-32.0.1700.68_beta1 Fri Dec 20 22:05:14 2013 >>> www-client/google-chrome-32.0.1700.68_beta1 Sat Dec 21 22:10:32 2013 >>> www-client/google-chrome-32.0.1700.68_beta1 Fri Jan 3 22:36:26 2014 >>> www-client/google-chrome-32.0.1700.68_beta1 Mon Jan 6 07:44:28 2014 >>> www-client/google-chrome-32.0.1700.68_beta1 Mon Jan 6 07:49:31 2014 >>> www-client/google-chrome-32.0.1700.68_beta1 Mon Jan 6 23:02:58 2014 >>> www-client/google-chrome-32.0.1700.68_beta1 Tue Jan 7 02:15:44 2014 >>> www-client/google-chrome-32.0.1700.68_beta1 Fri Jan 10 09:14:32 2014 >>> www-client/google-chrome-32.0.1700.72_beta1 Thu Jan 16 22:58:16 2014 >>> www-client/google-chrome-32.0.1700.77_p1 Thu Jan 16 23:06:58 2014 >>> www-client/google-chrome-32.0.1700.77_p1
Sounds like a bug. In fact, I think you've inadvertently switched from beta to stable channel (also note 32.0.1700.77_beta1 in the tree). The problem is, apparently _p1 is higher than _beta1. It's not obvious how to solve it, but with side-by-side (SxS) support being gradually enabled upstream, we should prevent such inadvertent switches from happening.
(In reply to Paweł Hajdan, Jr. from comment #1) > Sounds like a bug. In fact, I think you've inadvertently switched from beta > to stable channel (also note 32.0.1700.77_beta1 in the tree). > > The problem is, apparently _p1 is higher than _beta1. It's not obvious how > to solve it, but with side-by-side (SxS) support being gradually enabled > upstream, we should prevent such inadvertent switches from happening. It's supposed to be. https://devmanual.gentoo.org/ebuild-writing/file-format/ I don't see how that's relevant though.
Ohh, this is google-chrome. I thought we were talking about chromium. Yeah, the solution is to emerge google-chrome:beta.
(In reply to Paweł Hajdan, Jr. from comment #1) The most reliable way to prevent this would be to split the beta and unstable slots into separate package names, like: www-client/google-chrome (stable) www-client/google-chrome-beta www-clinet/google-chrome-unstable
I observed that issue from comment 1 also
(In reply to Mike Gilbert from comment #4) > The most reliable way to prevent this would be to split the beta and > unstable slots into separate package names, like: > > www-client/google-chrome (stable) > www-client/google-chrome-beta > www-client/google-chrome-unstable Let's do that. For now they'd need a blocker for each other one, but once side-by-side support fully works we'll be able to remove them. This is why we didn't split it that way previously, but now with side-by-side support almost ready the split makes more sense.
(In reply to Paweł Hajdan, Jr. from comment #6) I'm trying to figure out a "clean" way to do this, but I don't really see one. There does not seem to be any way to to a pkgmove for one slot. I could just drop the beta and unstable slots, but that will leave orphaned packages on people's systems. For the beta slot, a package.mask entry would probably work to get people to migrate. For the unstable slot, people will have this in package.unmask, so a package.mask entry will do no good. I guess they will be on their own to figure things out.
Ok, I have completed the migration. The package.mask entry summarizes it well: # Mike Gilbert <floppym@gentoo.org> (19 Jan 2014) # To prevent accidental switching of release channels (bug 498306), # google-chrome has been split into 3 packages: # # www-client/google-chrome # www-client/google-chrome-beta # www-client/google-chrome-unstable # # The stable channel remains as www-client/google-chrome, but has been # switched to SLOT="0". # # Please unmerge your currently installed version and remerge one of the new # packages. www-client/google-chrome:beta www-client/google-chrome:stable www-client/google-chrome:unstable
Just out of curiosity, why was www-client/google-chrome:beta in package.accept_keywords not working to fix the channel?
(In reply to Christoph Junghans from comment #9) > Just out of curiosity, why was www-client/google-chrome:beta in > package.accept_keywords not working to fix the channel? That would work fine on a stable system. However, on an ~arch system, it would have no effect whatsoever. The more critical issue is how the user invokes emerge. If they run "emerge www-client/google-chrome", then portage is going to flip-flop the slot any time we have a stable release and a beta release with the same version. If the user instead runs "emerge www-client/google-chrome:beta", then emerge will not randomly flip over to the "stable" slot. However, we have no way to force the user to invoke emerge in this manner. Splitting the package into three package names forces the user to make a conscious decision about which release channel to install, and this will keep portage from flopping back and forth between them.
(In reply to Mike Gilbert from comment #10) > (In reply to Christoph Junghans from comment #9) > > Just out of curiosity, why was www-client/google-chrome:beta in > > package.accept_keywords not working to fix the channel? > > That would work fine on a stable system. However, on an ~arch system, it > would have no effect whatsoever. > > The more critical issue is how the user invokes emerge. If they run "emerge > www-client/google-chrome", then portage is going to flip-flop the slot any > time we have a stable release and a beta release with the same version. > > If the user instead runs "emerge www-client/google-chrome:beta", then emerge > will not randomly flip over to the "stable" slot. However, we have no way to > force the user to invoke emerge in this manner. I see, but one could simply mask the other two channels, which might be a bit counter-intuitive. > > Splitting the package into three package names forces the user to make a > conscious decision about which release channel to install, and this will > keep portage from flopping back and forth between them.
