[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