- prereq.c (conflicts): detect conflicts
- prereq.c (prereq): pass list of conflicts of initial package
- test/conflict: regression test for basic conflict handling
- TODO: updated for partial implementation of conflicts
- Makefile (OBJS_qpkg): added fixup.o
- fixup.h, fixup.c (sort_versions): sort package versions
- qpkg.c (do_fixups, main): do fixups when done gobbling
- qpkg.h: need to include id.h to be self-contained
- test/sortver: test version sorting
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
Until now, when considering adding a package, we processed its
dependencies after completing the current list of dependencies. E.g.,
if we had a package A that depended on B and C, B depended on D, and C
depended on E, then the sequence would have been A, B, C, ...
We now process the dependencies of a package immediately after
considering the package, so the sequence above would become A, B, D,
C, ...
The advantage of the new order is that it becomes easier to follow the
dependency tree, which will be beneficial for loop detection and for
ordering packages by installation order.
- prereq.c (resolve): change prerequisite resolution order such that the
dependencies of the package being considered are processed immediately,
instead of deferring them until the end of the current dependency list
- prereq.c (prereq): we can now pass the list of dependencies directly,
without needing a list of lists element
- test/resorder: test resolution order
The original idea was to just copy "stack" (now called "installed") to
"best" when done. In this case, "best" would remain NULL if "install"
had no entries, which would then be interpreted as a failure to resolve
the prerequisites.
However, since we allocate a new list for "best" anyway, this concern
no longer exists, and we can also get rid of the contorted mechanism
that was designed to work around this problem. (It was never put into
action because I wanted to make a regression test for it first.)
- prereq.c (prereq): removed commented-out and nonsensical avoidance of
false error
- test/prereq: added test case with no prerequisite
- Makefile (test, tests, valgrind): new targets to run regression tests
- test/Common: test harness (adapted from fped)
- test/minpkg: test minimum package definition
- test/prereq: test basic prerequisite queries
