[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Detecting dependency cycles and conflict dependency problems in packages



* Nicolas Chauvat <chauvat@nerim.net> [011222 01:53]:
> [...] (I am using testing). [...]
> What I call a conflict dependency problem is something like (A conflicts 
> with B and B depends on A). I saw at least one case where this was on 
> purpose to facilitate upgrade, but I would say that it is an actual 
> problem in most cases.
> [...]
> A known limitation is that my script does not care about version numbers 
> and hence will probably report a number of false alarms.

I think this might be due to the nature of testing. If for example B
needs A and A and B have newer versions but the new version of A is
not compatible for use through B, this can only be reflected by making
A conflicting with to old B. 

This should normally be no problem, as the new A can do with the new B,
but this only holds for unstable. The alorithm for putting packages in
testing is still very simple. But even in the furure it will not be
able to detect all problems. To resolve the described situation, it
should not let B in, while A is not there, and not A in, while B is not
there. This would obviously not work. So it would not let B in, while
A is not there, and not let A in, while only A holds B back. Therfore
it would have to be able to detect, that a missing A in testing is the
only reason for B not going there. But now imagine the same situation
with three packages A, B and C whith (A and B) and (B and C) doing the
same line A and B in the previous example. Now A would not the only reason
for B not to go into testing, but also C. So it would need to see, that
while C is only waiting for A and B, and B is waiting for A and C, it
should install A to make the others follow. And then there are
situations, where A should enter testing fast, as it is needed by other
things and temporary breaking B is better then breaking more important
packages.

Note that I'm not involved in the testing-scripts, so most told here
are assuptions. But I hope you see the difficulty to keep testing
in consistency. ( But I you have an bullet-proof algorithm, that
also copes with the security issue and the other pitfalls, I think
many people will be happy, though I would not bet on anyone finding
one).

Hochachtungsvoll,
  Bernhard R. Link



Reply to: