mirror of
git://projects.qi-hardware.com/wernermisc.git
synced 2024-11-15 08:50:38 +02:00
0bc4b6046b
We define a cyclic dependency as the possibility (!) of the prerequisites of a package X including a package that depends on X, and issue an error if encountering such a situation. Note that, if the dependencies of X can be resolved in a manner that does not include the cyclic dependency, qpkg will still fail if it encounters the cycle. Also note that qpkg (at least so far) does no perform an exhaustive search to ferret out cyclic dependencies. Furthermore, we don't consider that a cyclic dependency may not necessarily imply a real life problem. E.g., if a package A contains elements X and Y, with X needing package B, and the content of package B has a run-time dependency on Y, the cyclic dependency between A and B would not exist when considering its constituents. Since we don't have this information, we just err on the side of caution. - qpkg.h (enum flags): divide flags into categories (parse-time and run-time) and add flag QPKG_ADDING to mark packets whose dependencies we are processing - prereq.c (resolve, prereq): track which packages we're tentatively considering for installation and detect cyclic dependencies - test/cyclic: regression test for detection of cyclic dependencies - TODO: updated with recent changes
53 lines
1.7 KiB
Plaintext
53 lines
1.7 KiB
Plaintext
Still left to do
|
|
================
|
|
|
|
- check whether introducing a new package would cause a conflict
|
|
|
|
- compile the list of conflicts of installed packages
|
|
|
|
- handle Provides:
|
|
|
|
- if there are multiple choices, try to prefer more recent versions
|
|
|
|
- sort prerequisites such that they can be installed in the specified order
|
|
|
|
- consider Architecture:
|
|
|
|
Update: we parse and record it now but don't use it yet.
|
|
|
|
- what to do with explicit and implicit replacement ?
|
|
|
|
- if we can't resolve the prerequisites, give at least a hint of what one
|
|
can do to improve the situation
|
|
|
|
- check database for internal consistency
|
|
|
|
Update: added detection of cyclic dependencies (in progress)
|
|
|
|
- implement keyword search
|
|
|
|
- consider also supporting the similar but not identical (parent ?) format
|
|
of /var/lib/dpkg/status and /var/lib/apt/lists/*Packages
|
|
|
|
|
|
Done
|
|
====
|
|
|
|
- optimize the search trees. Right now, we have 81812 calls to make_id
|
|
for 14601 packages, resulting in 7420560 calls to comp_id.
|
|
|
|
There can be at most 2 new identifiers per package (package name and
|
|
version), so a perfectly balanced tree should have a depth of no more
|
|
than 14. If we assume that each call to make_id searches to the bottom,
|
|
we'd get 1145368 calls to comp_id, about 15% of the current number.
|
|
|
|
So the tree is clearly degenerated.
|
|
|
|
Update: after switching to red-black trees, we get only 1497604 calls
|
|
to comp_id. This is 130% of the "good case" estimate above. Insertion
|
|
of a new node is currently done with two lookups, so we'll get rid of
|
|
some more lookups after further optimization.
|
|
|
|
Update: after merging the two lookups per new node into one, we're at
|
|
1172642 calls to comp_id, or 102% of the predicted "good case".
|