| 1 |
On 7 November 2013 04:15, Ian Stakenvicius <axs@g.o> wrote: |
| 2 |
|
| 3 |
> |
| 4 |
> The bug that was filed, is that a user didn't do a full emerge -uDN |
| 5 |
> @world prior to emerging (upgrading?) firefox, and they had icu-49 |
| 6 |
> already installed. Because the firefox dep didn't have a minimum |
| 7 |
> version, portage didn't see upgrading icu as a requirement before |
| 8 |
> firefox emerged. |
| 9 |
> |
| 10 |
|
| 11 |
Theres another scenario not listed here which can still happen: |
| 12 |
|
| 13 |
The end user has a copy of icu-49.ebuild somewhere in their portage layout |
| 14 |
still. |
| 15 |
|
| 16 |
Either this is due to a published overlay containing it, or them locally |
| 17 |
maintaining their own private overlay. |
| 18 |
|
| 19 |
The "update world" thing *may* still work in such a circumstance, but you'd |
| 20 |
have to change the policy to say "Update to a something that is in ::gentoo |
| 21 |
before merging packages from ::gentoo", which is getting a bit logically |
| 22 |
messy. |
| 23 |
|
| 24 |
Even then, it may not be apparent that there is a problem, for instance, if |
| 25 |
they have the overlay in place, *AND* they've locally masked newer versions |
| 26 |
of icu, for some reason ( perhaps they have 3rd party software they're |
| 27 |
locally maintaining that requires an older version of icu ). |
| 28 |
|
| 29 |
Here, the *only* sane approach is for firefox to declare it needs a certain |
| 30 |
version of icu as a minimum, regardless of what is, and what isn't visible |
| 31 |
in tree, so that the end user at very least gets told "firefox needs this", |
| 32 |
and its then their responsibility to sort out the problem if they've caused |
| 33 |
one. |
| 34 |
|
| 35 |
-- |
| 36 |
Kent |
Archives