[aur-general] [arch-general] Please settle 'base' in 'depends' for all

Allan McRae allan at archlinux.org
Wed Jan 19 09:25:15 EST 2011


On 20/01/11 00:07, Pierre Chapuis wrote:
> On Wed, 19 Jan 2011 23:59:55 +1000, Allan McRae <allan at archlinux.org>
> wrote:
>
>> Huh? How is no dependency checks (-Sd) equivalent to complete
>> dependency checking (-S with a transitive closure of dependencies)?
>> They are polar opposites.
>
> What I mean is that if a transitive closure of dependencies is
> performed at packaging time, then there is no need to check for
> dependencies when installing the original package.
>
> Here is an example:
>
> A depends on B and D
> B depends on C
> C depends on D and E
>
> Currently the deps will be:
>
> A -> B,D
> B -> C
> C -> D,E
>
> When installing A, Pacman will:
>
> 1) check deps for A, start installing B and D
> 2) check deps for B and D, start installing C
> 3) check deps for C, start installing E
>
> With a transitive closure scheme at packaging time, the
> deps would be:
>
> A -> B,C,D,E
> B -> C,D,E
> C -> D,E
>
> When installing A, Pacman could simply install B, C, D and E
> *without* checking their deps (-Sd) because these deps are
> necessarily already included in those for A.

The problem is that the transitive closure can not be assumed to be correct.

e.g.  At the time A is built:

A -> B,C,D,E
B -> C,D,E
C -> D,E

Then B is updated and

B -> C,D,E,F.

Now the assuming a transitive closure for the dependency list for A is 
incorrect.  Installing the listed dependencies of A with the equivalent 
of -Sd would result in F not being installed which would break A through 
broken B.

So either:
1) we require a largely unnecessary rebuild of A
2) we always check the dependencies of uninstalled dependencies.

Note #2 is less burden on packagers and is more efficient in the 
examples given above if both B and D are installed (two checks vs four), 
and that will be the case for most system updates.  When none of A - E 
are installed, they are probably equally efficient.

Allan


More information about the aur-general mailing list