1 |
*portage-2.1.5_rc1 (04 Apr 2008) |
2 |
|
3 |
04 Apr 2008; Zac Medico <zmedico@g.o> +portage-2.1.5_rc1.ebuild: |
4 |
2.1.5_rc1 release. In the event that a previously installed package has |
5 |
since been masked, emerge will no longer perform an automatic downgrade |
6 |
as part of a "world" update. You should either unmask such packages or |
7 |
else explicitly re-merge them in order to have them dowgraded to an |
8 |
unmasked version. Bug #216231 tracks all bugs fixed since 2.1.4.x. |
9 |
|
10 |
Assuming it's because of bug 197810, but that only talks about packages |
11 |
masked by corruption. But is it really so good to apply this also to |
12 |
keyword/package.mask or even ebuild being removed? |
13 |
|
14 |
For example, we had swt-3.3.1.1 in SLOT="3" and released swt-3.4_pre6 |
15 |
with SLOT="3". Later realized it's not backwards compatible enough and |
16 |
released swt-3.4_pre6-r1 in SLOT="3.4" removing the 3.4_pre6 ebuild. So |
17 |
I would expect the slot 3 to downgrade back to 3.3.1.1 (especially if |
18 |
something pulls slot 3 via slot dep). (Note that we can't use slotmove |
19 |
because changing slot in java package means also changing where it's |
20 |
installed and expected.) Now thanks to this change, downgrade won't |
21 |
happen. I think it's not good. |
22 |
|
23 |
VB |
24 |
-- |
25 |
gentoo-portage-dev@l.g.o mailing list |