As we prefer users to install the current -r2 over -r3 it should have a higher revision number than -r3. I suggest we copy -r2 as -r4 or something else higher to leave space for -r3 bumps. Doing this is required to be able to make sense out of the dependency graph that Portage gives you when 1.4.2 is masked and you don't remember that it is.
no, it's correct as is for both stable tree, and ~arch tree. you have to expliticely do something silly in /etc/portage/package.* to get it wrong. also, see bug 319457
and the next "fix" will be bug 324153, after which we can drop all KEYWORDS from libpng-1.2.43-r2.ebuild (or cvs remove it)
(In reply to comment #1) > no, it's correct as is for both stable tree, and ~arch tree. Every revision is a stable candidate. Try unmasking -r3 on a stable system. (In reply to comment #2) > and the next "fix" will be bug 324153, after which we can drop all KEYWORDS > from libpng-1.2.43-r2.ebuild (or cvs remove it) > Removing -r2 from tree works for me too.
(In reply to comment #3) > (In reply to comment #1) > > no, it's correct as is for both stable tree, and ~arch tree. > > Every revision is a stable candidate. Try unmasking -r3 on a stable system. wrong. it's not black and white like that because certain pkgs need other pkgs to go stable with them. what matters is the full state of either stable or ~arch tree. however i'm not going to start playing open-close bug games here...
(In reply to comment #4) > > wrong. it's not black and white like that because certain pkgs need other pkgs > to go stable with them. > what matters is the full state of either stable or ~arch tree. > And in that case the best way is to have those requirements expressed in dependencies.
it's gone now
