1 |
On 06/11/2013 17:26, Kent Fredric wrote: |
2 |
> |
3 |
> On 7 November 2013 04:15, Ian Stakenvicius <axs@g.o |
4 |
> <mailto:axs@g.o>> wrote: |
5 |
> |
6 |
> |
7 |
> The bug that was filed, is that a user didn't do a full emerge -uDN |
8 |
> @world prior to emerging (upgrading?) firefox, and they had icu-49 |
9 |
> already installed. Because the firefox dep didn't have a minimum |
10 |
> version, portage didn't see upgrading icu as a requirement before |
11 |
> firefox emerged. |
12 |
> |
13 |
> |
14 |
> Theres another scenario not listed here which can still happen: |
15 |
> |
16 |
> The end user has a copy of icu-49.ebuild somewhere in their portage |
17 |
> layout still. |
18 |
> |
19 |
> Either this is due to a published overlay containing it, or them locally |
20 |
> maintaining their own private overlay. |
21 |
> |
22 |
> The "update world" thing *may* still work in such a circumstance, but |
23 |
> you'd have to change the policy to say "Update to a something that is in |
24 |
> ::gentoo before merging packages from ::gentoo", which is getting a bit |
25 |
> logically messy. |
26 |
> |
27 |
> Even then, it may not be apparent that there is a problem, for instance, |
28 |
> if they have the overlay in place, *AND* they've locally masked newer |
29 |
> versions of icu, for some reason ( perhaps they have 3rd party software |
30 |
> they're locally maintaining that requires an older version of icu ). |
31 |
> |
32 |
> Here, the *only* sane approach is for firefox to declare it needs a |
33 |
> certain version of icu as a minimum, regardless of what is, and what |
34 |
> isn't visible in tree, so that the end user at very least gets told |
35 |
> "firefox needs this", and its then their responsibility to sort out the |
36 |
> problem if they've caused one. |
37 |
|
38 |
I agree with this sentiment. It's always been my view that the needs of |
39 |
a package are driven by the package itself, not by the tree. |
40 |
|
41 |
Rationale: A package will build and run as long as it's own requirements |
42 |
are met regardless of what the tree states. |
43 |
|
44 |
We have layman overlays and user's own overlays. Whilst these are not |
45 |
100% supported by Gentoo they are not banned either. They are also not |
46 |
"barely tolerated", it's more a case of overlays are not a problem and |
47 |
users are welcome to use them as long as they don't conflict with or |
48 |
break the tree for that user. |
49 |
|
50 |
This needn't be onerous. Presumably ebuild maintainers read the README |
51 |
and Changelog, these often state the versions of deps the package |
52 |
supports. Take that information and put it in the ebuild. Maintainers |
53 |
are under no obligation to provide the absolute minimum version of a |
54 |
dep, only at least one that will work. If the user decides to make other |
55 |
versions available to his system by whatever means, then portage can |
56 |
deal with it by and large transparently. |
57 |
|
58 |
|
59 |
-- |
60 |
Alan McKinnon |
61 |
alan.mckinnon@×××××.com |