Re: dependency resolution ?

On Fri, 2002-10-25 at 15:22, Patrick Devine wrote:
> On 10 Oct 2002, Peter Bowen wrote:
> 
> > On Thu, 2002-10-10 at 06:25, Alex Kramarov wrote:
> > > i thought packages should require only capabilities provided by other
> > > packages, not other package's files ! am i incorrect ? if i am, what other
> > > parts of packages redhat except "provides" and "files" packages can depend
> > > on ?
> > 
> > RPMS can depend on three things:
> > 1) Package names.  Sometimes RPM puts these in --provides, sometimes not
> > 2) Package "Tokens", which the things that --provides lists
> > 3) Packaged files.
> 
> These are really just examples of what Red Hat typically does.  The 
> value itself is can simply be treated as a string in most cases.  Red Hat 
> does include some notion of evaluation operators, but they're not really 
> used in Anaconda, and only make the dependency resolution slightly more 
> complex.

Unfortunately, not quite.

> 
> Writing a depency checker is fairly trivial, and you should be able to do 
> one with hash tables (which should be a lot speedier than the way Red Hat 
> does it).

Abandon all hope ye who enter here.

A 'mostly correct' dep resolver isn't too hard. Getting it right 99.9%
of the time is nearly inhuman. I remain unconvinced that it can be done
100% by any software.

> 
> First iterate through your collection of RPMs and determine what each 
> package provides.  ie:
> 
> apache -> [
> 	webserver
> 	libproxy.so
> 	mod_access.so
> 	mod_actions.so
> 	mod_alias.so
> 	mod_asis.so
> 	mod_auth_anon.so
> 	...
> 	apache = 1.3.22-6
> 	]
> ...
> 
> which you then turn into a hash table to resolve an individual  
> dependency by reversing the package and what it provides.  ie:
> 
> webserver -> [
> 	apache
> 	]
> libproxy.so -> [
> 	apache
> 	]
> mod_access.so -> [
> 	apache
> 	]
> ...

KABOOM.

The first thing that kills this particular design is that i686 glibc has
a provide that i386 glibc doesn't. (Or at least it used to - I had to
fix current just for that one package).

HOWEVER,
   Remember, you don't have to write a dep solver in the truest sense
here. Your goal is simply to answer the questions such a dep solver
might ask, which is a much simpler goal. 

'dep_string' -> [ full_on_package_that_provides_it.rpm, ditto.rpm, etc ]

But please don't think dependancy resolution is in any way easy.
Debugging the code that dealt with that in current required seeing what
the client wanted, and in one case, why the @##^$!@# it wanted it. Read 
through recent up2date versions dep solver to see just how tough this
can be.

> 
> Keep in mind that some things will resolve into more than one dependency, 
> so you might want to somehow incorporate a default value for a particular 
> resolution either by creating another hash table or by sorting the values 
> which are referenced by your dependecy key.  For instance, "tux" might 
> provide "webserver" as well, so you'll end up having to make a choice for 
> providing "tux" or "apache" to properly solve the dependency.



> 
> For quick dependency resolution of a static set of RPMs, you can also 
> build another hash of "requires" data and remove any unnecessary entries 
> from your first hash.
> 
> Also, you'll need to recurse through all of the results by rechecking any
> resolved dependencies to make certain that there aren't any additional 
> packages which need to be included.
> 
> --Patrick.
> 
> 
> 
> 
> _______________________________________________
> Current-server mailing list
> [email protected]
> http://lists.dulug.duke.edu/mailman/listinfo/current-server
> 
> 
-- 
Hunter Matthews                          Unix / Network Administrator
Office: BioScience 145/244               Duke Univ. Biology Department
Key: F0F88438 / FFB5 34C0 B350 99A4 BB02  9779 A5DB 8B09 F0F8 8438
Never take candy from strangers. Especially on the internet.