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