[aur-general] [arch-general] Please settle 'base' in 'depends' for all
Magnus Therning
magnus at therning.org
Wed Jan 19 07:49:43 EST 2011
On Wed, Jan 19, 2011 at 12:50, Allan McRae <allan at archlinux.org> wrote:
> On 19/01/11 22:20, Thomas Bächler wrote:
>>
>> Am 19.01.2011 08:08, schrieb Allan McRae:
>>>
>>> If we want to be really pedantic about dependencies, we should list
>>> _ALL_ dependencies and not remove the ones that are dependencies of
>>> dependencies.
>>
>> Why don't we just do the correct thing:
>>
>> If package A depends on package B, and B depends on C, then A might
>> depend on C explicitly because it accesses C directly. Or it might only
>> depend on indirectly C because B accesses C. We should reflect that in
>> dependencies (in the first case, A depends on C, in the second case it
>> doesn't).
>>
>> The result is this: Whenever the dependencies of B change (e.g., C is
>> removed), A will still work correctly.
>
> I agree that would be the correct thing to do. In fact, I looked at doing
> this to the extent of including ever package that a program linked to in its
> dependencies. This increases the number of dependencies needed for the
> average package in the repos greatly (from memory it averaged a several fold
> increase).
I don't quite understand what you mean, did you add the transitive
closure of all dependencies to the package, or did you only add all
direct dependencies?
> The side effect of that is there is obviously a correspondingly big increase
> in the number of dependency checks that pacman needs to do for each update
> and the associated speed hit. I always assumed that we did not list all
> dependencies for speed reasons.
Well, if the creation of the transitive closure of dependencies is
created at package build time, then it can be removed from pacman,
that should give a bit of a speed-up I suspect.
/M
--
Magnus Therning OpenPGP: 0xAB4DFBA4
email: magnus at therning.org jabber: magnus at therning.org
twitter: magthe http://therning.org/magnus
More information about the aur-general
mailing list