Petteri Räty wrote:
Vlastimil Babka kirjoitti:
*portage-2.1.5_rc1 (04 Apr 2008)
04 Apr 2008; Zac Medico <[EMAIL PROTECTED]> +portage-2.1.5_rc1.ebuild:
2.1.5_rc1 release. In the event that a previously installed package has
since been masked, emerge will no longer perform an automatic downgrade
as part of a "world" update. You should either unmask such packages or
else explicitly re-merge them in order to have them dowgraded to an
unmasked version. Bug #216231 tracks all bugs fixed since 2.1.4.x.
Assuming it's because of bug 197810, but that only talks about
packages masked by corruption. But is it really so good to apply this
also to keyword/package.mask or even ebuild being removed?
For example, we had swt-3.3.1.1 in SLOT="3" and released swt-3.4_pre6
with SLOT="3". Later realized it's not backwards compatible enough and
released swt-3.4_pre6-r1 in SLOT="3.4" removing the 3.4_pre6 ebuild.
So I would expect the slot 3 to downgrade back to 3.3.1.1 (especially
if something pulls slot 3 via slot dep). (Note that we can't use
slotmove because changing slot in java package means also changing
where it's installed and expected.) Now thanks to this change,
downgrade won't happen. I think it's not good.
VB
You can use atoms like <dev-java/swt-3.4_alpha:3 to force it
OK that solves my problem, thanks.
But in general case I think it's still wrong. Package is found to be
broken, gets p.masked, but people will keep the masked version and not
downgrade. And because it doesn't even warn about that fact, they won't
even know!
Caster
--
gentoo-portage-dev@lists.gentoo.org mailing list
