Re: About the Breaks: field.
Well, parsing the field into the backing store should not be a
problem, nor should writing it back. I'd like to discuss how we
handle the information.
Topological sorting involves setting up the packages and
dependency information in the for of a (sparse) graph; where each
package is a node (vertex) of the graph and the dependeny relations
are directed links.
T ensure that the graph is actually connected, two dummy nodes
are created, namely, START, and END, all packages are said to depend
on STAST, and END depends on all packages, so START makes an
excellent starting point.
The other links are formed as such:
a) depends is a simple directed link (the target is handled before
the dependent package).
b) predepends is like depends, except that special markedrs are
introduced that would cause a break in the processing so that the
predependency target is configured before unpacking the dependent
packages (this is external to the dependecy sorting process).
Target is configured before the dependent package. Requires
configuration of any package the target itself depends on.
c) Also independent of the dependency sorting process, some other
break point markers are introduced (configure immediately
requests, for example). All packages this depends on have to be
pkg-order can handle all above, so we have a working prototype
I'd like to discuss how to handle reverse-dependencies,
removals, conflicts, and breaks vis a vis the dependency ordering
Conflict handling: Error if conflicting package is not also
marked for removal. If conflicting package is marked for removal, the
removal happens before the new package is installed (this is a simple
Break: Error unless the package that is broken is not also
marked for removal. This is a link, with a marker to ensure the
removal is complete before the package is installed.
Replacement: the replaced package is to be removed before the
new package is handled. This is a simple link.
Reverse dependencies: If removing a package breaks other
packages, than those packages should also be marked for removal. All
thse packages should be removed before the target package is removed
(this is a simple link)
Dependency handling: We should have the dependencies checked
_pretending_ that the packages to be installed are installed,
and packages to be removed are removed.
If a what if dependency check fails, then we have to handle
that, possibly asking for user input.
Please pardon me if this does not make sense, I have a 103
degrees F fever while writing this, so this maybe mere delerium.
If atheism is to be used to express the state of mind in which God is
identified with the unknowable, and theology is pronounced to be a
collection of meaningless words about unintelligible chimeras, then I
have no doubt, and I think few people doubt, that atheists are as
plentiful as blackberries... Leslie Stephen (1832-1904), literary
Manoj Srivastava <url:mailto:firstname.lastname@example.org>
Mobile, Alabama USA <url:http://www.datasync.com/%7Esrivasta/>