1 |
On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka <kensington@g.o> wrote: |
2 |
> |
3 |
> In general, a package must explicitly depend upon what it directly uses. |
4 |
> However, to avoid ebuild complexity and developer burden there are some |
5 |
> exceptions. Packages that appear in the base system set may be omitted |
6 |
> from an ebuild's dependency list in the following circumstances: |
7 |
> |
8 |
|
9 |
So, I'm not a big fan of implicit dependencies in general. What does |
10 |
the new policy buy us that the existing one does not? Why not try to |
11 |
find a way to ditch implicit dependencies entirely? If the issue is |
12 |
that nobody wants to have a laundry list of dependencies in every |
13 |
package, why not use something like a virtual to pull in all the |
14 |
commonly-used stuff. Then for the 0.1% of the tree where it matters |
15 |
we could list things explicitly so that we don't have a big pile of |
16 |
packages that portage can't parallelize. |
17 |
|
18 |
It seems like the problems with the current approach are: |
19 |
1. @system can vary by profile, which allows bugs to creep in since |
20 |
maintainers can't stay on top of what is and isn't always in @system). |
21 |
2. PMs can't build @system packages in parallel, since it doesn't |
22 |
know what the real deps are. |
23 |
3. The way we use @system makes it hard to tell if it is safe to |
24 |
remove some package which is otherwise heavily-used. You never really |
25 |
know if you can safely do without bash, and so on. (Note, this bit |
26 |
wouldn't be helped at all by simply turning system into a big |
27 |
virtual.) |
28 |
|
29 |
I'm not entirely sure what problem you're trying to solve, so the |
30 |
above may or may not be helpful. I'm fine with incremental |
31 |
improvements if they actually improve something. Otherwise, the |
32 |
status quo does have the benefit of simplicity - you don't have to |
33 |
list @system packages as dependencies ever, but you can do so if you |
34 |
wish or it brings some benefit (deps on specific versions/slots, |
35 |
slot-operator deps, etc). |
36 |
|
37 |
-- |
38 |
Rich |