| Summary: | google-chrome-32.0.1700.77_p1: profile directory name changed from google-chrome-beta to google-chrome | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Konstantin (elxa) <ktrackfd> |
| Component: | Current packages | Assignee: | Chromium Project <chromium> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | alex_y_xu, grubba, junghans |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
|
Description
Konstantin (elxa)
2014-01-17 01:22:20 UTC
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 (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. |
