1 |
On 14/11/14 01:17, Rich Freeman wrote: |
2 |
> On Thu, Nov 13, 2014 at 5:30 AM, Michael Palimaka <kensington@g.o> wrote: |
3 |
>> |
4 |
>> In general, a package must explicitly depend upon what it directly uses. |
5 |
>> However, to avoid ebuild complexity and developer burden there are some |
6 |
>> exceptions. Packages that appear in the base system set may be omitted |
7 |
>> from an ebuild's dependency list in the following circumstances: |
8 |
>> |
9 |
> |
10 |
> So, I'm not a big fan of implicit dependencies in general. What does |
11 |
> the new policy buy us that the existing one does not? Why not try to |
12 |
> find a way to ditch implicit dependencies entirely? If the issue is |
13 |
> that nobody wants to have a laundry list of dependencies in every |
14 |
> package, why not use something like a virtual to pull in all the |
15 |
> commonly-used stuff. Then for the 0.1% of the tree where it matters |
16 |
> we could list things explicitly so that we don't have a big pile of |
17 |
> packages that portage can't parallelize. |
18 |
|
19 |
The problem is the current policy is not particularly clear - the issue |
20 |
of when to explicitly specify a system dependency keeps coming up. The |
21 |
first two sentences say all system dependencies are implicit and should |
22 |
not be specified, while contradicted by the third in some (but not all |
23 |
cases). |
24 |
|
25 |
Ditching implicit dependencies is an interesting idea but not practical. |
26 |
Nobody wants to the laundry list, and there's little benefit in |
27 |
maintaining a virtual/system clone of @system. |
28 |
|
29 |
> It seems like the problems with the current approach are: |
30 |
> 1. @system can vary by profile, which allows bugs to creep in since |
31 |
> maintainers can't stay on top of what is and isn't always in @system). |
32 |
> 2. PMs can't build @system packages in parallel, since it doesn't |
33 |
> know what the real deps are. |
34 |
> 3. The way we use @system makes it hard to tell if it is safe to |
35 |
> remove some package which is otherwise heavily-used. You never really |
36 |
> know if you can safely do without bash, and so on. (Note, this bit |
37 |
> wouldn't be helped at all by simply turning system into a big |
38 |
> virtual.) |
39 |
> |
40 |
> I'm not entirely sure what problem you're trying to solve, so the |
41 |
> above may or may not be helpful. I'm fine with incremental |
42 |
> improvements if they actually improve something. Otherwise, the |
43 |
> status quo does have the benefit of simplicity - you don't have to |
44 |
> list @system packages as dependencies ever, but you can do so if you |
45 |
> wish or it brings some benefit (deps on specific versions/slots, |
46 |
> slot-operator deps, etc). |
47 |
|
48 |
This is just about clarifying things. The wording of the current policy |
49 |
is vague ("don't depend on system dependencies, but consider sometimes |
50 |
doing it") and I think something more explicit would be better. An |
51 |
update would help better reflect reality too - most people depend on |
52 |
app-arch/bzip2 for libbzip2 even though it's in @system. |