| 1 |
On Wed, 10 Aug 2011 23:14:22 +0200 |
| 2 |
Fabio Erculiani <lxnay@g.o> wrote: |
| 3 |
> I've intermittently spent my last two days trying to figure out a |
| 4 |
> weird bug on Entropy dependency resolution algorithm (which is |
| 5 |
> actually just a simple topological sorting out of a digraph) |
| 6 |
|
| 7 |
You can't use a naive topological sort to do dependency resolution. |
| 8 |
RDEPEND-RDEPEND cycles are legal and common. |
| 9 |
|
| 10 |
> Entropy always tried to strictly follow PMS (bugs apart). Given the |
| 11 |
> same document, about PDEPEND it says something like this: there is no |
| 12 |
> guarantee that a PDEPEND gets installed at a certain, specified point |
| 13 |
> during the schedule, if not specifically listed as RDEPEND by some |
| 14 |
> package. |
| 15 |
> The problem here is that Portage enforces the same rule by trying to |
| 16 |
> schedule the PDEPEND "as soon as possible", which leads ebuild writers |
| 17 |
> to think to have gotten the deps order right. |
| 18 |
> In simple words, it doesn't seem that Portage itself follows PMS or |
| 19 |
> PMS is detailed enough. |
| 20 |
|
| 21 |
Portage *tries*. There's no guarantee that it will succeed. If you need |
| 22 |
a particular ordering, you can't use PDEPEND. If something's there only |
| 23 |
because of a PDEPEND, there are absolutely no guarantees whatsoever as |
| 24 |
to when it will get resolved; PDEPEND imposes absolutely no reliable |
| 25 |
conditions upon ordering. Any ebuild assuming otherwise should be fixed. |
| 26 |
|
| 27 |
Purely as a quality of implementation issue, scheduling a PDEPEND |
| 28 |
reasonably soon after (or even before) the package requiring it may be |
| 29 |
a good idea, simply because users may get confused if when they try to |
| 30 |
install a bunch of things and one of those things gets installed long |
| 31 |
before related packages. But you can't rely upon that happening. |
| 32 |
|
| 33 |
(Incidentally, one could also argue that package manglers should always |
| 34 |
try to come up with the most perverse legal ordering possible for any |
| 35 |
situation. That way bugs will be identified much more quickly. Part of |
| 36 |
the problem with Portage is that it has so many tricks and so little |
| 37 |
error checking that broken things quite often appear to work.) |
| 38 |
|
| 39 |
-- |
| 40 |
Ciaran McCreesh |
Archives