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